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 <[email protected]> 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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
