New system-config-acpid

Thomas Woerner twoerner at redhat.com
Wed May 7 15:17:57 UTC 2008


Bastien Nocera wrote:
> On Wed, 2008-05-07 at 09:29 +0200, Zdenek Prikryl wrote:
>> Bill Nottingham napsal(a):
>>> Not to be a killjoy, but why a config tool for a program which should
>>> probably die? Aren't these all better handled by user-specific policy
>>> agents such as gnome-power-manager or kpowersave?
>> Simple reason :-)... if you don't use gnome or kde or this applets, the simplest
>> way how to get things work is configure this daemon.
> 
> Not really. With HAL running, it should push the ACPI key events through
> D-Bus. There's no need for a system-config-acpid or even using acpid.
> 
>> On the other hand I agree, that better way is catch this events via HAL and then
>> send it to d-bus. But in this case, again, you have to have this applets. AFAIK
>> there is no "acpid" for dbus which you can configure for any acpi events (like
>> Fn5 which should enable bluetooth).
> 
> With the right keymap, all those events already trickle to X, so there
> shouldn't ever be a need for acpid or a system-config-acpid, as there's
> already enough hot-key handlers in X (such as the ones builtin to GNOME
> and KDE).
> 
Please also think about systems without a running X server: Yes, there 
are still some server installations out there. Fedora might be some kind 
of desktop system, but keep in mind that we also need a solution for EL.

> Do we still install acpid by default?
> 
Yes, and we should not drop it without having a replacement, which is
1) working without X
2) not contingent on any desktop environment
3) only configurable if you use a special desktop environment

We need a solution for this, the machine has to react in the same manner 
on acpi events with and without a desktop environment. There should also 
be a configuration tool for a server environment: A tray-applet is not a 
solution here, because there is no X and no tray.

Thomas




More information about the devel mailing list