On Sun, 2007-12-02 at 10:00 +0100, Michael Biebl wrote: > I also noticed, that pm-utils is still sub-optimal on ppc > architectures. E.g pm-is-supported does not seem to correctly detect > pmu support, and whenever pm-utils is installed, hal will use > pm-is-supported to set the power_management.can_* keys, thus g-p-m > will not offer this option anymore in the gui.
I guess we need to fix this in pm-utils. An easy fix I guess. > I have to add, that pm-utils in Debian does not ship pm-pmu (it was > removed by the Debian maintainer deliberately), as we tried to make > pm-utils an arch:all package (only shell scripts) Please don't do this. > and provide the pmu > functionality (together with support for all the other quirks) in one > single binary No, that's no how it is supposed to be put together. > , s2ram from the uswsusp package [2]. Apparently this has > led to problems [3] for people using pm-utils, but don't have the > uswsusp package installed. Why do you need to use pm-utils and uswsusp? Doesn't the kernel method work? It sounds like this is packaged in an odd way. > The question now is, where to put this pmu support: hal, pm-utils or s2ram? > I personally would like to remove hal-system-power-suspend-linux from > hal, pm-pmu from pm-utils (so pm-utils becomes a arch:all shell script > only package) and move all the nasty stuff into one binary, s2ram, > which then deals with stuff like poking /dev/pmu, VBE save/restore > etc. No. s2ram should just _do_ the suspend, not muck about with quirks and poking pmu - the pm-utils infrastructure should do this. The "nasty stuff" is what we are trying to fix in a nice clean way that users can fix and push upstream. Thanks. Richard. _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
