How to intercept all keyboard events

[Daniel]

On Sat, Sep 25, 2010 at 10:26 PM, <wettstein509 at solnet.ch> wrote:

> > 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.
>

This looks very intriguing and could indeed solve my problem. But please
clarify something for me. I need to intercept *all* keys with a main
interest keys that normally print characters. So when you mention
"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.", are you talking about a limitation in this approach
for my problem, or is it possible to override already taken keys with an
action binding? (I think it's the latter, but just to make sure before I
start patching my X server).

Apart from that what is the core teams stance on the bug report? Is there a
defined behavior and this is a bug, or is there some deeper reason behind
the current implementation? Running permanently with patched versions is
acceptable, but if it would be fixed, it would obviously be better.


>
> > 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.
>

Hmm, I think this would actually not work for me, because I'm trying to
recognize more key combinations (by analyzing the key event stream) than the
standard modifiers give me out of the box, and then to execute actions on
different programs based on it. A bit like system wide shortcuts on
steroids. This means that either I need between detecting the combination
patterns and executing the actions a communication channel that allows to
carry that many distinct signals, or both aspects must be implemented in the
same place and I need to be able to invoke all actions directly. Your
approach with action messages gives me the ability to do the processing in
the WM, so I could implement the second version in a comfortable way. Right
now it looks like this is the better approach to pursue.

Thanks for the detailed response, it helped a lot.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20100926/31813206/attachment.html>