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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list