Perry E. Metzger wrote:
> "Steven M. Bellovin" <smb@cs.columbia.edu> writes:
>   
>> When I'm in X and suspend, on resume I see a blank screen with a blinking
>> VGA-type cursor in the upper left.  I can restore my X by switching
>> consoles away from screen 5 and then back.
>>     
>
> This is not surprising. S3 is allowed to power off *everything* but
> memory, so the state of the video chip is lost. On restore we do a
> reset of the video, but we don't know what the state of the chip was
> before sleep. X effectively manages the drivers entirely in userland,
> so unless X decides to re-initialize the display it is going to be
> screwed up.
>   

This is another example of why, IMO, the architecture of X talking
directly to registers is an incredibly bad idea.

The hardware driver (e.g. radeonfb in my case) should have power hooks
and manage this all without disrupting display consumers.  Xwsfb will
eventually work like this, I hope. :-)
> One thing we can do, though, is use the same protocol that is used
> when we switch from a particular vt console back to X to tell the X
> server to take control back of the screen.
>   

Yes, that should work.

    -- Garrett
>   
>> A brief test of cardbus slots after resume succeeded -- my EVDO card was
>> able to dial out.
>>
>> Speedstep, via estd, is *not* working; the speed stays at 1800 Mhz.
>>     
>
> I think that's handled by the same chip that handles the USB stuff --
> we're failing to re-initialize it properly.
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191