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