How to intercept all keyboard events

[wettstein509 at solnet.ch]

> I would like to have permanent exclusive access to keyboard events and
> the possibility to drop arriving events and create new ones before
> they are finally delivered to the application over the normal X
> channels (window with keyboard focus, grabs).

I believe I have a solution, but it is not simple, and currently
requires a small bug in the X-server to be fixed before it can work
(#28575 in the freedesktop bugzilla).  It goes as follows:

We create an XKB keymap in which all physical keys we want to intercept
have a message action mapped to them, for example:

    key <AE07> {
        type= "ONE_LEVEL",
        repeat= No,
        symbols[Group1]= [        NoSymbol ],
        actions[Group1]= [ ActionMessage(report=all, data="Hello") ]
    };

Message actions have two important benefits: Applications which ask for
them get them all (presses and releases, when 'report=all' is used as
above), and applications that do not ask for them do not get anything,
not even a usual key event (by default; this can be changed by an option
to ActionMessage).

The intercepting client uses the extension XTest to generate artificial
key events for keycodes that have no physical keys associated to them.
These keycodes have normal keysyms mapped to them, and these artificial
key events is all usual clients see from keyboard activity.

I have been using this approach with a patched X-server for a couple of
months (for a trivial tool that admittedly could be implemented easier
using the XRecord extension), and it works.

In principle, applications other than the intercepting client could ask
for message actions.  However, as usual keymaps do not use message
actions, the odds that this really happens are low.  Practically, I
believe the greatest problem in this modern world with all its
multimedia keyboards is to find keycodes that are guaranteed not to be
taken by real keys.

> So what do people do in similar situations? I think that input
> methods, and accessibility related projects need to solve a similar
> problem. Although I feel that both problem areas are a lot more
> complex than mine, as they need to provide UI interaction, which I
> don't.

As far as I can tell (but I am not an expert), input methods do not
allow to create events with modifiers (such as Control-X).  Some input
methods allow to create events such as a keysym Backspace, but not all
applications treat this event as they would treat hitting the backspace
key.  This might or might not be relevant for you.

Apart from UI, one thing that input methods can do that the proposal
above can not is to create arbitrary input characters; the proposed
approach is restricted to what is in the keymap.

Andreas