[Pm-utils] [PATCH 1/2] Enable autodetection and stacking of sleep methods.

[Stefan Seyfried]

Victor Lowther wrote:
> On Tue, 2008-09-16 at 11:34 +0200, Tim Dijkstra wrote:

>> We could also just drop 99video and just use s2ram that would be much
>> easier in maintaining. ;)
> 
> well, my experience suggests the opposite. Right now s2ram will die
> horribly on systems running opensource nv drivers on nvidia g80 class
> hardware, because it requires special handling that HAL and pm-utils
> take into account,

How so?
seife at stoetzler:~/projects/powermanagement/pm-utils> grep -r video.rom .
./pm/sleep.d/99video:   local rom="/var/run/video.rom"

The file is never created, so pm-utils does nothing else than s2ram, since the
file is never created it will not use it.

If I knew where the magic video.rom file comes from, the support in s2ram
would be pretty trivial to do.

>> So if you add all the work that all pm-utils maintainers have to do, their
>> is no maintenance benefit to remove uswsusp support. So I urge you to not
>> apply your patch.

> As far as maintanance goes, a quick perusal of the git changelogs should
> give you an idea about how familiar I am with maintaining pm-utils.

nobody is doubting your number of commits. However, every package maintainer
wanting to use s2ram will have to patch his package again.

>>> Right.  And once pci_state and no_fb support is merged, there will be no
>> functional difference between 99video and s2ram, except that s2ram has
>> an internal whitelist that pm-utils ignores by design in favor of the
>> quirks that HAL gives us.

The whitelist in s2ram will die sooner or later (actually if I had time, it
would probably be already gone). However, it will still provide an easy,
failsafe and fast method to do all the quirks in one place, without lots of
dependencies etc. But that's for the users to decide which way they want to
use it.

> Well, right now pm-utils and HAL seem to be getting more traction w.r.t
> new quirks.  If you are volunteering to get s2ram up to the point where
> it does everything 99video does, be my guest.

Right now I don't see much that 99video does and s2ram doesn't. Since you
don't create the video.rom file anywhere, that part will never be used.
Everything else (resetting brightness for example) that is not done by s2ram
is done so on purpose: with the brightness infrastructure in place now, it is
the kernel's task to reset brightness on resume. If the kernel doesn't do it,
then that's a kernel bug and that should be fixed, not worked around.

Remember that back in the "old days", we consciously decided not to workaround
fixable bugs in pm-utils and s2ram, only stuff that cannot be fixed in kernel
(or that's unacceptably ugly to do in the kernel, like the vbetool and
radeontool stuff) would be worked around.
And it was a good decision to do so: much more bugreports against broken
drivers were filed and the drivers were fixed because we e.g. did not unload
all the known broken device drivers etc. I think the same still applies today
and I'm keeping it like that in my version.
-- 
Stefan Seyfried
R&D Team Mobile Devices            |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)