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