*Which app will capture my input?*
Various protocols are available under X to remap keys and alter response to key input (alt, ctrl, meta, et al.). Is there a clear way to understand what takes precedence, for instance, when you have (language dependent) alt-mapped keys, a window manager, terminal, and tmux that expect to use the same key-combinations to do different things?

I think one way to test this would be to set the same keybind on all levels and have something log when the event is captured, and then disable them when you find they were captured by one layer.

I'll try to see if I'm able to test this, at least with the ones you mentioned: WM, tmux, terminal, command line tool, etc..

As fas as I know, the basic and most common cases are something like this:

1. X11: Grabbed keys, e.g. hotkey daemons or dmenu.
   
2. X11: Window that has input focus.
   
3. Terminal: Is a regular X11 client, first of all. Translates X11 key events into bytes that are fed into the master end of a pseudo terminal.
   
4. tmux: Reads from its pseudo terminal slave, has no idea about X11. Doesn't see "Ctrl" or "Alt", really, it's either an XOR 0x40 (for Ctrl) or a sequence (for Alt). tmux processes its own hotkeys and passes anything else on a second pseudo terminal master to the application (probably, haven't checked, but it wouldn't make a lot of sense otherwise).
   

As for the pseudo terminal stuff, eduterm might be interesting.

And then there is stuff like XInput2, which can just read everything, ignoring that hierarchy. Just run `xinput --test-xi2 --root`.

There's also XRecord, IIRC. (Maybe that's implemented via XInput2 these days, no idea.) Lots of ways to write key loggers on X11.

This might be interesting: https://wiki.archlinux.org/index.php/Key...es_in_Xorg but it kinda stops at the X11 level while 'our' problem occurs after that.

Some info on the process can also be found here: https://gitlab.com/interception/linux/to...bevdev-sit

Actually, could you clarify what you mean by this part?

Quote:Various protocols are available under X to remap keys and alter response to key input (alt, ctrl, meta, et al.)

Are you assuming that key events are filtered at runtime by the program that remaps them? I always thought that tools like xbindkeys change "the key map" and then quit. Like changing the keyboard layout from qwertz to qwerty. But I never had a deeper look at the details here.

(17-11-2020, 04:31 PM)vain Wrote: Are you assuming that key events are filtered at runtime by the program that remaps them?

I don't think so, at least not in most cases. But maybe it's better to be careful about what I mean by "mapping":

1). xkb mapping --> linking hardware keypress to keysymbol understood by X
2). application key mapping --> linking client functionality to specific key input

In applications, (2) are sometimes hard-coded, or maybe they can be changed to correspond to something else in a config somewhere. Most programs probably don't mess with (1) for their own functionality.

My mental model of the situation is that X has it's keyboard setup (via xkbmodel, xkblayout, xkbvariant, xkboptions) these determine which hardware keys correspond to specific input that X reads. From there, (I guess) lots of X protocols are available to pick up the mapped input. I assume most applications use this mapped input.

Individual clients can take advantage of X protocols (directly or most likely through some library) to listen, intercept, maybe in rare cases block keyboard input.

In my setup my keymap uses alt for accented letters ( żćęą ) so any application that expects e.g. alt-a, won't see it as the keyboard sends the code for "ą".

Meanwhile, my WM responds to function keys via mapping that I have specified in my window manager config. I press F9, keycode 75 (keysym 0xffc6, F9) and my window manager creates and jumps to a new workspace. If I run MidnightCommander (which expects F9 to focus the menu) the mapped function keys do nothing in MC.

Nice discussion of keyboard input here:

https://unix.stackexchange.com/questions...utput-work

Good details and some history on Meta key input from Thomas Dickey:

https://unix.stackexchange.com/questions...s-meta-key

So apparently the "Compose" key in xorg is ⇧ Shift + AltGr (while pressing AltGr before ⇧ Shift is the "fourth keyboard level modifier", a different key).

Also: https://github.com/rrthomas/pointless-xcompose