[Pm-utils] Why do we still ship hal-system-power-pmu / PMU support suboptimal in pm-utils

[Richard Hughes]

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.