Video PM Methods

[Stefan Seyfried]

On Tue, May 16, 2006 at 07:41:36PM +0100, Richard Hughes wrote:
> On Tue, 2006-05-16 at 20:30 +0200, Stefan Seyfried wrote:
> > This can be set in /proc/sys/kernel/acpi_video_flags
> 
> Cool, thanks. Any idea what to echo for each case as I just have "0" in
> that file.

from "s2ram -h" :-)
    -a, --acpi_sleep: set the acpi_sleep parameter before suspend
                      1=s3_bios, 2=s3_mode, 3=both

> So:
> 
> video_adapter_pm.vbe_restore would be a better name so that we could use
> restore and save or get and set to do the same thing?

Oops, i am probably not understanding correctly.
Just because some machines work with vbemode get/set does not mean that
there are no machines that need vbestate save/restore :-)
So i think we need different bools, for
    vbestate_restore
    vbemode_restore
    vbe_post
    dpms_force (maybe called suspend_dpms?)
i am not sure about radeontool, maybe the "vbetool dpms off" is enough for
the radeontool machines also, i have to test that.

where they reside in the device tree etc. is nothing i can comment on.

> > just use s2ram?
> 
> I really want to use fdi-matches, rather than a compiled black/white
> list. Also using HAL scripts, all this is easy to do with little shell
> scripts without any new deps.

well, the suspend package will be needed in the near future anyway for
suspend to disk, so s2ram will be present (or probably be folded into
the suspend binary) an all machines. So you actually avoid the dependency
on vbetool and maybe radeontool.
Additionally, s2ram has the advantage that it does not crap out before
restoring the video (there might still be problems with some SATA drivers
so you cannot access the disk after resume from RAM. Unfortunately vbetool
cannot reanimate your backlight and you never will read the error messages
... :-)

I think that fdi files might be a good idea for the blacklist (don't tell
pavel that i said this :-), but i will still use s2ram to "apply" the
information i got from the fdi files.
 
> Surely it's easy enough to just add it directly to a small
> hal-system-foo bash script?

yes, of course.

> > Oh - and some machines will only resume from RAM when running on VGA console
> > or vga16fb, but not on vesafb or any other framebuffer, many newer DELLs and
> > HPs with ATI cards are prominent examples.
> 
> Hmm.. how do we work round this other than setting vga= stuff on the
> kernel command line?

We can't. s2ram right now refuses to suspend those machines and tells the
user that he has to use plain vga console. Of course OS installers could
use this information to configure vga=0 automatically.
-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen