VideoAdapterPM.SuspendVideo

[Tim Dijkstra]

On Fri, 06 Oct 2006 18:45:04 +0100
Richard Hughes <hughsient at gmail.com> wrote:

> On Fri, 2006-10-06 at 16:00 +0200, Stefan Seyfried wrote:
> > 
> > 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.
> 
> So, at the moment we have a best-of-breed approach:
> 
> * program invokes Suspend() on HAL
> * HAL invokes hal-system-power-suspend
> * hal-system-power-suspend (using the quirks assigned using
> video_adapter_pm) executes pm-suspend with flags (e.g. --s3mode)

HAL can just invoke pm-suspend with those flags. We can drop
hal-system-power-suspend.

> * pm-suspend runs all the hacky scripts (e.g. to set LED's, rmmod
> modules and sync drives etc.) and then runs s2ram.
> * s2ram actually does the suspend (using whatever method) and resumes
>   the video
> * pm-suspend does all the hacky resume stuff (modprobe'ing, setting
> led's)
> * the Suspend() method on HAL returns.
> 
> Is this sane? It seems very complicated. 

This is less complicated than how it is done now, IMHO.

> This means that console users
> of pm-suspend will also not get the video resumed like they do at the
> moment.

Hmm, that is a good point... also in either scheme people that don't
use HAL won't get the video resume. We could teach s2ram to read fdi
files... 

grts Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20061006/a4077e55/signature.pgp