G-P-M on the wrong track?!

[Richard Hughes]

On Sun, 2005-10-16 at 12:26 +0200, Matthias Grimm wrote:
> Hi,
> Richard might not like to hear this but I think the G-P-M development
> is on the wrong track.

Criticism is always good. I know I'm enthusiastic but sometimes you need
to take a step back.

> It started with the aim to build a GUI for power
> management features. So far so good. But in the meantime it piles more
> and more power management functions and because it runs with user
> privileges and need someone to do the dirty work, clutters HAL with low
> level power management functions which it is not designed for.

Hmm, disagree here. HAL is used as a "Hardware Abstraction" daemon.

For example:

I want to get a UPS's charge. I search for all the battery objects with
type "ups"

I then use hal to get battery.percentage_charge

I want to get a laptop battery charge. I search for all battery objects
with type "primary"

I then use hal to get battery.percentage_charge

The same with wireless mice and keyboards.

You see? One abstracted interface using very different information
stores (serial, acpi, csr).

Also putting all the ACPI data in HAL has let us fix *many* broken
BIOS's, so that any userspace application doesn't have to care about the
specific details. I know its not such an issue for the PMU laptops out
there, but ACPI is broken more of the time than working.

> Continuing this path will cause a dilemma for the end user: He has to
> decide between a well working power management (for example on powerpc
> machines, see pbbuttons.sourceforge.net) and the gnome desktop, because
> G-P-M has the GUI he or she likes but the functionallity breaks all
> other power management concepts (daemons).

Yes it breaks concepts. It uses DBUS to lock down who can do what, so
that the default desktop user doesn't have to enter a root password to
change a hibernation setting.

I agree HAL support has not great support for powerpc at the moment, but
the basics are in place.

See http://gnome-power.sourceforge.net/powerbook.php for why.

> I would like to suggest a slightly change of project aims:
> 
> 1. HAL
> The HAL specifications tells that HAL provides a view and detailed
> metadata to attached hardware, not more. Not a word about building the
> mega-system-do-everything daemon.

Then what's the point in HAL? To provide a nice tree showing our PCI and
USB hardware? That's looking at HAL without an objective stance, I
imagine C++ where you can perform a method on an object, the same as
read it's properties. A lot more powerful than just reading in the
properties.

HAL doesn't "do everything" -- it now provides a sane abstraction for
devices (in my opinion). You can call SetLCDBrightness on a LCD panel
device, or Suspend on the Computer device, but that's about it for the
scope of methods.

The beauty of using HAL addons is that the acpi method is only run for
acpi systems, the csr addon is only for wireless battery and mouse etc.
You do not have to start one system service like apmd, or acpid or pmud
on install, HAL will start the correct addon(s) automatically depending
on your hardware.

> Please return to this aim. Limit HAL's functionallity to collect data
> from various sources and provide it to the desktop for visualisation.

What's the point? That limits hal to being a flashy version of lspci and
lsusb when it has *so much more* potential.

> According to the specification it is not HAL's task to actively control
> certain hardware or start scripts because of desktop programs wanted so.

I depends on what you define HAL as. I agree, HAL used to be more of a
"Hardware Reporting Daemon" and now it's more like true hardware
abstraction.

David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
got no reason to think that he's not okay with the direction HAL has
taken. (David, speak up if you have!)

> 2. G-P-M (Desktop Part)
> The G-P-M project description on gnomefiles.org sais: "The main focus
> here is the user interface; e.g. allowing configuration of power
> management from the desktop in a sane way"

It is sane. No root passwords, no funky permissions files to change and
no detail about newbie-unfriendly concepts such as ACPI, PMU and APM.

> This is exactly what G-P-M on the Desktop should do. Visualize data
> provided by HAL and comunicate with a power management daemon through
> dbus, but don't perform any power management functions by itself.

When I was designing g-p-m, I was going down the route that you
explained. There was a system initscript that launched a daemon that
spoke to HAL, and the daemon then spoke to g-p-m. This was so complex it
was never going to work. Speaking to people, it became obvious to me (it
was spelt out to me!) that this middle daemon was not required at all.
The policy could be done in g-p-m as a user-session daemon.

Think about it. How many users do you have logged in to graphical
desktop environments on your laptop right now? For me it's one, so the
"session daemon controls the system" idea is valid. On a server with
multiple user logins, each with a DE, I don't expect to have g-p-m
installed (or running in each user session), as it's not required. And
even if it was installed it wouldn't work as the DBUS permissions are
locked down by default.

The permission structure is a lot like NetworkManager in this regard.

> 3. The Power Management Daemon
> Power management is too critical to lay it in user's hands. It is an
> important system feature and must be handled by a system daemon running
> with high privileges. No desktop program is able to fulfil this task.

Why not? I'm a user, and I want to suspend my laptop after 10 minutes of
inactivity. Assuming I'm logged in as a console user (i.e. sitting at
the physical keyboard) I can set this to 10 minutes in g-p-p, and then
g-p-m will use gnome-screensaver's information about my inactivity so
that after 10 minutes, g-p-m tells HAL to suspend (hal calls the
distro-specific scripts) and it "just works".

> Divide G-P-M in two parts (projects):
>  part 1: Desktop module which visualize interesting data to the user
>          including configuration dialogs
>  part 2: a power management daemon that do the dirty work, provide data
>          to HAL and receive orders from desktop programs through dbus.

What "orders" would it take? What data does it provide? As soon as you
start fleshing out the detail (i.e. formal design) it all gets
horrendously complex.

> This concept has a lot of advantages:
>  - It won't break with existing power management structures. Migration
>    is possible in small steps,

Why is that an advantage? On my system now, I can install g-p-m, a
pretty recent HAL, and (potentially) remove:

toshutils
apmd
acpid
apmd
pmud
ial
FnFX

And I can setup most typical actions in g-p-m. The old setups will still
work, there's nothing *forcing* you to use g-p-m over a custom perl
script that lives in /etc/acpi/events.d

Talking to real world users (i.e. proficient with power-management and
linux) they have intricate scripts written in perl, sh and some C that
do actions on a hardcoded events (and writing handlers for all their own
hardware). For a non-power user, /etc/acpi/events.d is a scary place.

>  - The user can use the Desktop tools with a power manager he likes,

Same as now. Talking to the KDE guys at LinuxWorld UK (we went out for
beers afterwards, no blood spilt...) they liked the idea of the HAL
information store for PM, and said it could be built into the existing
KDE framework (where they now talk directly to the ACPI and APM
hardware). They could switch to using HAL to do a suspend in a few lines
of code (and potentially remove *lots* of system specific code).

>  - the new power management daemon will cooperate with all desktops,
>    not only with Gnome,

HAL does that job now. In KDE4 HAL plays a more prominent role.

>  - HAL can fulfill its job straight forward. No foreign code anymore.

Depends on your definition of foreign. If you mean code that is a bit
different to the standard device stuff, then I think it has actually fit
in quite well.

> There are sill a lot of questions to answer but I think this concept is
> future proof and bring power management on Linux a step forward. There
> are a lot of good ideas in G-P-M and a lot of highly motivated and
> entusiastic people push it forward with breathtaking speed

Urm... You trying to say I should get out more :-) I'm taking that as a
compliment :-)

>  but it seems to me that the big plan is incomplete or missing at all.

There is a plan, but the plan keeps changing :-)
Like the kernel, if there's found a better way to do something then they
don't mind changing things (breaking compatibility) and upsetting
people. Just like the HAL LCD brightness API change.

> Also everything
> is eyed through the Gnome spectacles only but power management is not a
> Gnome only issue.

Hence using HAL. HAL is cross platform and cross environment.

> I have developed pbbuttons (power management daemon for Linus on Apple
> computers) for four years now and I would be pleased to join the team
> developing the new power management daemon I described above.

I've seen pbbuttons, and I'm quite impressed. There's lots of code that
could be used by HAL directly (like the communicating with PMU), without
the additional overheads of the another management daemon.

I don't want to be seen as obsoleting pbbuttons with g-p-m, as for
powermac hardware, pbbuttons is by far generations ahead. The things is,
pbbuttons is specific to PMU hardware which makes it unsuitable as a
core GNOME application. If you think as g-p-m as ACPI only (which is
could be) then the apple user experience is going to be vastly different
to the ACPI experience. I think we need to unify the many architectures
into a common entity. Which is why HAL is important.

> I'm awaiting your feedback.

Cheers for your email, I hope I've answered some of your questions and
worries. Sorry for the super long email.

Richard.