G-P-M on the wrong track?!

[Matthias Grimm]

On Wed, 19 Oct 2005 20:45:01 -0400
David Zeuthen <david at fubar.dk> wrote:

> > 10. Switch off not used hardware (mostly done in kernel, difficult
> >     task for user space programs, therefore only very basic support for
> >     this is implemented in pbbuttonsd)
> 
> Not even done in the kernel - runtime power management as I understand
> is still something left to implement.

Yes, runtime power management sould be done transparently in kernel
without even noticed by the user. 

> > 12. launch customer specific scripts at certain events (change of power
> >     source, lid close/open, change of power policy
> >     (powersafe/performance), etc)
> 
> We just do things right and no customer specific scripts are needed. Oh,
> if you do want this HAL already supports it but I'd rather see things
> getting done right without customer specific scripts.

Humans need dreams, don't they? :-) You can't do all things right.
There are always people that want start a script at certain events.
 
> > 13. change most of the behaviour described above depending on power
> >     source (time to dim, time to sleep, etc.)

> Clearly you want this daemon in the desktop session so it can read
> settings using the desktop configuration system. Because if you don't
> read settings from there you miss out on the great features that e.g.
> gconf offers

I like Gnome but gconf is a gnome specific configuration database and
not every ppc user uses gnome. I won't disappoint pbbuttonsd users using
KDE or any other desktop system. Furthermore it makes no sense to have
separate power policy managers (like G-P-M) for Gnome, KDE, XFCE, etc
all doing the same job. It will be work enough to create the
configuration GUIs for all different desktops. So gconf is not a option
for system daemons.

> Suggesting to read settings from a file in e.g. /etc is the old UNIX way
> and I think at this point many many people think that config files
> in /etc just isn't what we need in 2005. I'm curious if you agree?

What's wrong with /etc? I think we will still have configuration files
stored in /etc in 2015. Many famous programs use /etc for their
configuration files. /etc is widely accepted and gconf (and any other
configuration database) has a log way to go for that.

Don't get me wrong. I'm not against configurations databases but my
programs mostly operate on system level and I have to use methods that
are widely available and keep dependencies low. I would disappoint a
lot of users if I choose one or another desktop dependent configuration
system.

Maybe, some day someone starts an independent configurations database
project with a simple and easy to use API that get what it takes to
replace /etc or at least is accepted to work in parallel, I would
be pleased to use it.

> >  7. save hardware modes (see 5.) so that they survive suspend-to-ram.
> 
> Specifically point 7. I see as a duty of the suspend/hibernate scripts
> until all this mess is properly fixed in the kernel / X.org.

I don't think this will ever fixed in kernel because the drivers for
this devices are stable and development have been stopped. This problem
will remain for user space forever. And regarding the scripts: You wanted
to do things just right and don't use any scripts, right? :-)

This problem could be easily solved if a hardware module could register
a callback on suspend and one on resume where such things could be done.

The HAL driver for the "PowerBook ADB Trackpad" would then register a
callback and HAL will call it on suspend and resume. In the callback
function the driver will read the current device configuration and
reset it after resume. That's it. 

> I believe that we for some time have trapped ACPI buttons. I believe
> that Richard has patches for the IMHO rather stupid kernel modules
> (toshiba) that use vendor-specific interfaces. Thus, we'll end up with
> the same nice abstraction we already use for ACPI buttons. What's wrong
> with teaching HAL about this?

At first, most of the keys on Apple Powerbooks emits standard keycodes
through the input layer and need no further handling by any daemon. The
only thing left to do is to connect the keys with functions which could
be done on desktop level in a user session.

The rest of unsupported keys as well as ACPI buttons needs some care.
HAL could do this job, read the key informations and forward the
keycodes to uinput as Richard already started to implement. If you like
to store additional information about this buttons in the HAL tree,
it't up to you to do so but to send those key codes to uinput will be a
clean and nice way to distribute key events and many keyboard application
programmers would appreciate this, I'm pretty sure about that.

> Remember if I'm e.g. IBM/Dell/Toshiba/Sony/whoever I can just send a
> patch to the HAL mailing list and get support (or fix my driver or the
> kernel to do the right thing)

Have you ever thought about a driver plugin system? So that the HAL
upstream source haven't to be patched on every new driver or driver
update? A programmer could write a driver plugin for certain hardware
devices and distribute them on his own or contribute it to the HAL main
package. But he doesn't need to patch a foreign code.

> > Most of the points in the first group and point 2. of the second one
> > should only run once per machine, so I think the user session, where it
> > will be lauched once per user is not the right place. Beside this some
> > of the functions should also work if no user is logged in or even
> > depend on X. 
> 
> Well, 99.999% of the time people are logged in. For the very rare and
> very uninteresting case where people are not logged in my proposal is to
> run g-p-m / g-h-m from gdm as user nobody and without any UI. Oh, you
> also want to run the screensaver, this is exactly the same problem. 

And where is the difference to running g-p-m (without GUI) as
system daemon independent from X then?.

Btw I don't use any screensaver on my Laptop. The PM daemon will dim the
display and put the machine to sleep at the end instead. I spend no
battery power for drawing silly graphics to an unwatched screen. And why
spending a separate process for swithing of the display? ;-)
What a pitty that screen locking is unnecessarily bound to the screensaver.

> I'm not terribly opposed to the "put special button events such as 'Web
> Browser' on uinput" idea, it's something we can easily add.

I think we now agree on this issue.

> > > Btw, it is my view that anything else related to power management should
> > > be handled in-kernel, e.g. run time power-management (dynamically
> > > adjusting power management of certain devices, e.g. suspend a USB
> > > thumbdrive using USB PM).
> > 
> > It does already a lot of that stuff, but some task are still left to be
> > done by user space programs :-)
> 
> Yea, I still think most of the things we want belong in the kernel. I
> mean, ideally users should never tweak power management policy settings,
> our defaults should just rock.

Nothing to add here :-)

 Best Regards
   Matthias