[systemd-devel] hardware/system keys/buttons

[Tormen]

Hi David,

Thanks for the answer !

Ok... I see: The mechanism to handle keycodes is not necessary for the 
power button I suppose ;)
But still it seems that not a lot would be missing in systemd to allow 
to react to keycodes ?

As you mentioned: Auto assigning keysyms gets messy (different hardware, 
differnt keyboard layouts) -> I would start simple and use keycodes.
(it's what actkbd does)
Also: How important would portability (from one machine to another be)?

> Furthermore, how would you like this to be implemented? Should systemd
> spawn one client every time a configured key is pressed? Doesn't sound
> very efficient to me.

I have to admit I am relatively new to systemd and don't know exactly 
how the "lid-switch" or "power-button" are handled...
... but in these cases you need to be able to run a command
... and either wait for it to finish before relistening on new 
keystrokes or spawn the command to the background

 > Every other idea I had is either inefficient or ugly.
Do you know actkbd ?
http://users.softlab.ece.ntua.gr/~thkala/projects/actkbd/

I guess what they do is OK
... efficient because based on kernel input events
... ugly: the setup - I would say no, as every hardware is different, 
the setup needs to be different...
... but flexible as it allows to react on key press / on key release

actkbd.conf:
# <keys>:<event type>:<attributes>:<command>

# <keys> == 110 or 110+93. use "actkbd -n -s" - shows keycodes without 
executing
# <event type> == OPTIONAL comma/whitespace separated list: ḱey [press] 
/or/ rep[repeat] /or/ rel[ease]; defaults to "key"
# <attributes> == OPTIONAL comma/whitespace separated list: - see 
/learn/it/actkbd/attribute-list
# <command> == passed to system() - to have non-blocking behaviour, you 
have to append the "&"!

Tormen

---

On 26/12/12 17:31, David Herrmann wrote:
> Hi Tormen
>
> On Wed, Dec 26, 2012 at 4:25 PM, Tormen <quickhelp at gmail.com> wrote:
>> Aargh! I tried to be clear ... and was not ;)
>>
>>
>>> I would like to trigger events on my notebook hardware keys and
>>> independent of any X environment!
>> I would like to react to input events [triggered by hardware keys] on my
>> notebook
>> and this independent of any X environment.
> The problem that you will encounter here is that this mechanism will
> only work for keycodes. That is, you can react on the code that is
> associated with the physical key. If you want to react on keysyms
> (which is probably what most people want), you need keyboard handling
> (like XKB, xkbcommon, KBD). However, this will become very complex and
> you want different keyboard-layouts to be configured etc...
> Hence, in my opinion integrating this into systemd won't simplify this
> in any way. Listening via udev on event devices and opening them via
> /dev/input/eventX should be fairly straightforward.
>
> Furthermore, how would you like this to be implemented? Should systemd
> spawn one client every time a configured key is pressed? Doesn't sound
> very efficient to me.
>
> I also want a daemon that can react on key-presses independent of
> xserver, but I haven't found any nice way to provide this but
> listening for key-presses in the application itself. Every other idea
> I had is either inefficient or ugly.
> So maybe a library providing such functionality is the best idea?
>
> Regards
> David