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