VideoAdapterPM.SuspendVideo

Stefan Seyfried seife at suse.de
Fri Oct 6 07:00:32 PDT 2006


On Thu, Oct 05, 2006 at 11:22:41PM -0400, David Zeuthen wrote:
> On Sat, 2006-09-30 at 10:49 +0200, Tim Dijkstra wrote:
> > Anyway, as I understand now, pm-utils calls hall to suspend the video
> > cards. But what happened to: "hal depends on pm-utils, not the other way
> > around"? This way pm-utils is less generic then promised; you can't
> > usefully get the machine to sleep without hal.
> > 
> > BTW, I think you're aware of suspend.sf.net, there they have some more
> > options to get the graphics card to behave.
> > 
> >     -s, --vbe_save:   save VBE state before suspending and restore
> > 	after resume.    
> >     -p, --vbe_post:   VBE POST the graphics card after
> > 	resume 
> >     -m, --vbe_mode:   get VBE mode before suspend and set it after
> > 	resume 
> >     -r, --radeontool: turn off the backlight on radeons before
> > 	suspending. 
> >     -a, --acpi_sleep: set the acpi_sleep parameter before
> > 	suspend 1=s3_bios, 2=s3_mode, 3=both
> 
> So I'm not super excited either about pm-utils calling into HAL. I do
> think, however, having the quirk information in a well-defined format
> (e.g. hal fdi files) is important. 
> 
> How about this approach:
> 
>  1. pm-suspend / pm-hibernate takes parameters such as the above,
>     e.g. you can specify the quirks on the command line.
> 
>  2. when HAL invoke pm-suspend / pm-hibernate it passes the quirks
>     on the command line. We get this from FDI files.

This is pretty much what i had in mind. "Use HAL as the whitelist database
but let the pm-utils decide what to do with this information".
No, having the whitelist compiled into s2ram is not my favorite solution :-)
But with this, pm-utils can just call s2ram with the apropriate flags, so
the built-in whitelist gets overridden, or they can do everything by
themselves using vbetool, radeontool, etc.pp.
 
>  3. when resuming, pm-suspend / pm-hibernate saves the last passed
>     options in a configuration file somewhere if that location
>     is writable. User should be able to tweak that configuration
>     and specifically tell pm-suspend / pm-hibernate not to touch
>     it at all

Here i like the last suggestion (drop a fdi file somewhere and prompt
the user to submit it) best. With this approach i have had quite a lot
of reports for s2ram :-)

> I think that's a bit nicer. Thoughts?

I like it.

-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 


More information about the hal mailing list