[pxc]

'Q' isn't a scancode, though. The scancode is some weird number. 'Q' is a symbol, what the Linux keyboard tools project calls a 'keysym'.¹ The displeased users are expecting the symbolic-looking name to behave like a keysym in xmodmap or various WMs, and thus to be mapped according to layout. But in Wayfire, it's a short name for a scancode based on the mapping for QWERTY.

Imo it makes sense to support defining mappings according to both modes of reference, and even allow mixing them into a single config. Neither way of thinking seems inherently better or worse to me. Just depends on preference, intuition, and expectations.

--

1: https://www.man7.org/linux/man-pages/man5/keymaps.5.html

[dasyatidprime]

That's the same thing I was getting at, yes. When I said “KEY_Q in the header file”, I was referring to the #define that attaches it to a number (edit to clarify: in linux/input-event-codes.h, specifically, which seems most likely to be the source of calling these KEY_* in the context of a Wayland compositor) and pointing out how it doesn't actually map to the conceptual Q, and that's why I mentioned scancodes specifically. Keysyms are indeed a separate layer, and I agree that users expecting to be able to configure on keysyms and being given the QWERTY-derived scancode mapping instead is confusing.