Hacker News Reader

Comment by ammen99 | Hacker News Reader

Bindings respond to a particular hardware key code. If you have a qwerty keyboard, when you press the key labeled as 'Q', the keyboard sends a `KEY_Q`. If you take a different physical device, `KEY_Q` will probably be reported for the key where `Q` is written on the new keyboard.

View on HN

This is contrary to my understanding of mainstream keyboard technology. Scancodes, like what you're looking at with Linux input, mainly refer to physical positions relative to a “standard” keyboard, and the labels in the header file for the alphabetic section are based on assuming the keyboard is QWERTY. A keyboard that comes from the manufacturer with different-layout keycaps on it will still output physical-position-based scancodes, and KEY_Q in the header file is not normally generated by the key that the manufacturer shipped a cap labeled Q on; it's the key in the position that would output Q if it were a QWERTY keyboard. (Though there's a few edge cases around e.g. ANSI vs ISO layout.)

This idea is corroborated if you look in the USB HID Usage Tables that the Linux input event codes are based on. From https://usb.org/document-library/hid-usage-tables-14:

> Note: A general note on Usages and languages: Due to the variation of keyboards from language to language, it is not feasible to specify exact key mappings for every language. Where this list is not specific for a key function in a language, the closest equivalent key position should be used, so that a keyboard may be modified for a different language by simply printing different keycaps. One example is the Y key on a North American keyboard. In Germany this is typically Z. Rather than changing the keyboard firmware to put the Z Usage into that place in the descriptor list, the vendor should use the Y Usage on both the North American and German keyboards. This continues to be the existing practice in the industry, in order to minimize the number of changes to the electronics to accommodate other languages.

This can get somewhat more complicated when you get into keyboards with custom remapping firmware where they do actually shift the scancodes around, but that creates other potential issues, and users who are doing that basically just have to deal with their own integration tradeoffs. Similar considerations apply to keyboards with non-mainstream physical layouts.

'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

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.

Reply on news.ycombinator.com