VideoAdapterPM.SuspendVideo

[Tim Dijkstra]

On Tue, 03 Oct 2006 17:47:39 -0400
Peter Jones <pjones at redhat.com> wrote:

> 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.
> 
> Yeah, it's a problem with no good solution.  Really, when it comes down
> to it, *something* has to actually do suspend+resume methods for all
> hardware.  Normally this is the kernel.  In the case of video, nothing
> wants to do it.

Yes, but I prefer that 'something' would be less dependent on other
libs, daemons, etc. 
You are aware of suspend.sf.net? I must admit having a compiled-in
whitelist is not exactly great at this stage... But I like the idea of
just producing some binaries that do what they promise: s2ram, s2disk,
s2both. Wouldn't it be a good idea to build pm-utils around that?

> I'd argue it should be the kernel for video, too, but developers are not
> going to be happy with where that train of thought leads us :(

I agree with you there. There are more 'quirk tables' in the kernel that
work around buggy hardware. The truth is of course, that video in Linux
is a bit of a mess. Parts live in the kernel, yet other parts live in
that userspace part of the kernel that is called X (even worse parts
live in non-free drivers) and now yet another piece is needed to get
suspend/resume to work... 

grts Tim