VideoAdapterPM.SuspendVideo

David Zeuthen david at fubar.dk
Thu Oct 5 20:22:41 PDT 2006


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.

 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

I think that's a bit nicer. Thoughts?

    David




More information about the hal mailing list