I would like to hook into, intercept, and generate keyboard (make/break) events under Linux before they get delivered to any application. More precisely, I want to detect patterns in the key event stream and be able to discard/insert events into the stream depending on the detected patterns.
I've seen some related questions on SO, but:
I explain the problem below, but to make it a bit more compact and understandable, first a small DSL definition.
A_
: for make (press) key AA^
: for break (release) key AA^->[C_,C^,U_,U^]
: on A^
send a make/break combo for C and then U further down the processing chain (and finally to the application). If there is no ->
then there's nothing sent (but internal state might be modified to detect subsequent events).$X
: execute an arbitrary action. This can be sending some configurable key event sequence (maybe something like C-x C-s
for emacs), or execute a function. If I can only send key events, that would be enough, as I can then further process these in a window manager depending on which application is active.Ok, so with this notation, here are the patterns I want to detect and what events I want to pass on down the processing chain.
A_, A^->[A_,A^]
: expl. see above, note that the send happens on A^
.A_, B_, A^->[A_,A^], B^->[B_,B^]
: basically the same as 1. but overlapping events don't change the processing flow.A_, B_, B^->[$X], A^
: if there was a complete make/break of a key (B) while another key was held (A), X is executed (see above), and the break of A is discarded.(it's in principle a simple statemachine implemented over key events, which can generate (multiple) key events as output).
So the basic question is how to implement this.
I have implemented a solution in a window manager using passive grabs (XGrabKey
) and XSendEvent
. Unfortunately passive grabs don't work in this case as they don't capture correctly B^
in the second pattern above. The reason is that the converted grab ends on A^
and is not continued to B^
. A new grab is converted to capture B if still held but only after ~1 sec. Otherwise a plain B^
is sent to the application. This can be verified with xev
.
I could convert my implementation to use an active grab (XGrabKeyboard
), but I'm not sure about the effect on other applications if the window manager has an active grab on the keyboard all the time. X documentation refers to active grabs as being intrusive and designed for short term use. If someone has experience with this and there are no major drawbacks with longterm active grabs, then I'd consider this a solution.
I'm willing to look at other layers of key event processing besides window managers (which operate as X clients). Keyboard drivers or mappings are a possibility as long as I can solve the above problem with them. This also implies that the solution doesn't have to be a separate application. I'm perfectly fine to have a driver or kernel module do this for me. Be aware though that I have never done any kernel or driver programming, so I would appreciate some good resources.
Thanks for any pointers!
Use XInput2 to make device(keyboard) floating, then monitor KeyPress and KeyRelease event on the device, using XTest to regenerate KeyPress & KeyRelease event.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With