[systemd-devel] hardware/system keys/buttons

[Lennart Poettering]

On Wed, 26.12.12 16:21, Tormen (quickhelp at gmail.com) wrote:

> Hi,
> 
> I would like to trigger events on my notebook hardware keys and
> independent of any X environment!
> (very useful to do all sorts of things when something went south in
> your graphical environment)
> 
>     (a) systemd is already reacting to the power button and lid switch (!)
>     (b) part logind is already listening to *all* possible input
> event sources:

Not really "all". Just the the ACPI input devices (i.e. all input
devices tha are marked with the "power-switch" udev tag).

> Dec 04 09:55:07 seven systemd-logind[1126]: Watching system buttons
> on /dev/input/event3 (Sony Vaio Keys)
> Dec 04 09:55:07 seven systemd-logind[1126]: Watching system buttons
> on /dev/input/event4 (Sony Vaio Jogdial)
> Dec 04 09:55:07 seven systemd-logind[1126]: Watching system buttons
> on /dev/input/event2 (Power Button)
> Dec 04 09:55:07 seven systemd-logind[1126]: Watching system buttons
> on /dev/input/event1 (Lid Switch)
> 
> ... so the necessary infrastructure to react to all sorts of
> input/events is in place (*)
> and already used, but seemingly (?) limited to power buttons.

As David pointed out, this is not really the case. 

> ... wouldn't it be nicer to flexibly allow the treatment of all
> sorts of input events to give the user the freedom to decide how to
> use systemd's capability to listen to system/hardware keys/buttons
> and react to them ?

Hmm, we catch the power/suspend events because they are a really
low-level system event and their handling should always work and is par
tof the basic lifecycle of the system. 

I am a bit afraif of feature creep here. I mean, not everything really
has to be handled in systemd itself. For many things an external daemon
is not wrong. For example for handling other ACPI events but
suspend/power we still allow people to install acpid in parallel to
logind, precisely because we believe that not everything should be
handled by systemd/logind, and anything more specialized should be
handled by specialized.

So, yeah, I am a bit conservative on this one. Both because I am not
sure it would belong in logind, and because of the keysym issue David
pointed out.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.