Video PM Methods

[Peter Jones]

On Tue, 2006-05-16 at 17:54 +0100, Richard Hughes wrote:
> Right, lets re-open the discussion:
> 
> I agree having three types of video card (ati, nvidia, intel) was
> probably over-generalising the quirks needed and we need finer-grained
> control for some videocards.
> 
> To resume from video suspend we may have to use (one or many of):
> 
> 1. S3_BIOS kernel boot option
> 2. S3_MODE kernel boot option
> 3. vbetool post
> 4. vbetool vbestate save <and> vbetool vbestate restore
> 5. vbetool dpms suspend  <and> vbetool dpms on
> 6. radeontool?
> 
> How do we handle the kernel parameters? Should we check the grub
> commandline to make sure we have the correct parameters and fail to
> suspend the video if not set correctly?

That won't help -- most of the time fbcon drivers are modular.

> 
> How do we specify, for instance, that my intel video card needs to do:
> 
> vbetool vbestate save
> vbetool dpms suspend > foo
> <suspend>
> vbetool dpms on
> vbetool vbestate restore < foo
> 
> How about:
> 
> video_adapter_pm.vbe_state_restore (bool)
> video_adapter_pm.vbe_post (bool)
> video_adapter_pm.dpms_force (bool)
> 
> And then we can have:
> 
>   <device>
>     <match key="/org/freedesktop/Hal/devices/computer:smbios.system.manufacturer" string="Acer">
>       <match key="/org/freedesktop/Hal/devices/computer:smbios.system.version" string="TravelMate 650">

Are you sure you really want this, rather than pci
vendor:device:subvendor:subdevice for the video card?  BenH was telling
me the other day that he's had good experience moving to the pci IDs
rather than the DMI system-type field for the whitelisting of pm stuff
in the radeonfb code.
-- 
  Peter