swsusp / 2.6.0-test1

swsusp / 2.6.0-test1

[Andreas Jellinghaus]

Hi,

swsusp is working fine, but mplayer
in sdl and xv output mode displays a blank
screen after a resume. 

Piii, debian unstable, dell latitude c600, 
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3
AGP 2x (rev 02)
CONFIG_DRM=y
CONFIG_DRM_R128=y

what else shall I post, or how can I debug the problem?

other issues:
 - hostap driver 0.0.3 doesn't work. But pcmcia stop/start
   fixed it. but that required a kernel patch anyway, as
   hostap still isn't part of the kernel and thus maybe not
   up to date (don't know).
 - there are at least two suspend events, one for pressing
   and one for releasing the key. I wrote a script that
   creates a pid file and removed it 30 seconds later -
   and in the mean time ignored any request to suspend.
   (if you press the suspend key longer, you get even more events.)

Regards, Andreas

Re: swsusp / 2.6.0-test1

[Andreas Jellinghaus]

On Mon, 2003-07-21 at 18:38, Andreas Jellinghaus wrote:
> swsusp is working fine, but mplayer
> in sdl and xv output mode displays a blank
> screen after a resume. 

I meant to write:

star mplayer: works fine.
end mplayer
suspend
resume
start mplayer: no video
end mplayer
start mplayer -vo sdl: no video
end mplayer
start mplayer -vo x11: video.
(but x11 video output does not scale the video to full screen.)

Andreas

Re: swsusp / 2.6.0-test1

[Pavel Machek]

Hi!

> swsusp is working fine, but mplayer
> in sdl and xv output mode displays a blank
> screen after a resume. 

What kernel version?

> Piii, debian unstable, dell latitude c600, 
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3
> AGP 2x (rev 02)
> CONFIG_DRM=y
> CONFIG_DRM_R128=y
> 
> what else shall I post, or how can I debug the problem?

You probably need to write suspend/resume support for your card.

								Pavel


> 
> other issues:
>  - hostap driver 0.0.3 doesn't work. But pcmcia stop/start
>    fixed it. but that required a kernel patch anyway, as
>    hostap still isn't part of the kernel and thus maybe not
>    up to date (don't know).
>  - there are at least two suspend events, one for pressing
>    and one for releasing the key. I wrote a script that
>    creates a pid file and removed it 30 seconds later -
>    and in the mean time ignored any request to suspend.
>    (if you press the suspend key longer, you get even more events.)
> 
> Regards, Andreas
> 

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: swsusp / 2.6.0-test1

[Pavel Machek]

Hi!

> >>swsusp is working fine, but mplayer
> >>in sdl and xv output mode displays a blank
> >>screen after a resume. 
> >>   
> >You probably need to write suspend/resume support for your card.
> >
> 
> Just wondering what kind of support for suspend/resume is "enough", say 
> for video cards? Surely not the pci configuration space, you need to 
> restore video mode, color maps, gfx engine state etc etc...what about 
> frame buffer contents on card? Probably yes. Sounds like a lot of code, 
> and different thing for every possible video card. Is there some general 
> guidance here? Is drivers/video soon bloating with tons of 
> suspend/resume code? I hope I am wrong :)

I'm not sure if you are wrong. If you switch  to non-graphics console,
that may save some code, but...

BTW vger.redhat.com, what is that?
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: swsusp / 2.6.0-test1

[Mika Penttilä]

Pavel Machek wrote:

>Hi!
>
>  
>
>>swsusp is working fine, but mplayer
>>in sdl and xv output mode displays a blank
>>screen after a resume. 
>>    
>>
>
>  
>
>You probably need to write suspend/resume support for your card.
>
>								Pavel
>  
>

Just wondering what kind of support for suspend/resume is "enough", say 
for video cards? Surely not the pci configuration space, you need to 
restore video mode, color maps, gfx engine state etc etc...what about 
frame buffer contents on card? Probably yes. Sounds like a lot of code, 
and different thing for every possible video card. Is there some general 
guidance here? Is drivers/video soon bloating with tons of 
suspend/resume code? I hope I am wrong :)

--Mika

Re: swsusp / 2.6.0-test1

[Pavel Machek]

Hi!

> ah ok, so at this stage swsuspending a X desktop doesn't work in general 
> case, of course depending on video hardware? If X had some notion of 
> suspend/resume things would be easier, than insisting every single 
> driver save and restore all. After all the pci config space should be 
> enough for kernel drivers?

Look how swsusp handles it: we switch to text console (which means X
gets told to bring vga card to some sane state). We should do the same
for S3.

I'm using vesafb, which needs no special support for suspend/resume
;-). [And its very good for system stability; with notebook's LCD I
don't care about low refresh (1).]
								Pavel
(1). I've seen notebooks LCD flashing at 25Hz, but VESA modes are
fortunately better than *that*. 
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: swsusp / 2.6.0-test1

[Mika Penttilä]

Pavel Machek wrote:

>Hi!
>
>  
>
>>>>swsusp is working fine, but mplayer
>>>>in sdl and xv output mode displays a blank
>>>>screen after a resume. 
>>>>  
>>>>        
>>>>
>>>You probably need to write suspend/resume support for your card.
>>>
>>>      
>>>
>>Just wondering what kind of support for suspend/resume is "enough", say 
>>for video cards? Surely not the pci configuration space, you need to 
>>restore video mode, color maps, gfx engine state etc etc...what about 
>>frame buffer contents on card? Probably yes. Sounds like a lot of code, 
>>and different thing for every possible video card. Is there some general 
>>guidance here? Is drivers/video soon bloating with tons of 
>>suspend/resume code? I hope I am wrong :)
>>    
>>
>
>I'm not sure if you are wrong. If you switch  to non-graphics console,
>that may save some code, but...
>
>  
>
ah ok, so at this stage swsuspending a X desktop doesn't work in general 
case, of course depending on video hardware? If X had some notion of 
suspend/resume things would be easier, than insisting every single 
driver save and restore all. After all the pci config space should be 
enough for kernel drivers?



>BTW vger.redhat.com, what is that?
>								Pavel
>

Don't know, just did reply all and seems to work :)

--Mika