i know this was probably supposed to be funny but it’s a very frustrating comment to me. we’ve fielded this issue at length but have received precious little assistance in moving it forward. the OS does not actually help us much since we are not running in a console or X window.
not really. the kernel doesn’t care about keyboard locale. the kernel maps scan codes to keycodes. (this lowest-level mapping can itself be customized, but that’s not typically done for localization - more for things like like swapping CTL and ALT.) userspace maps keycodes to characters when appropriate - in
localectl for virtual terminals, in xorg for windowed apps, or just in application code for things like
evtest which use the USB data directly instead of requiring a terminal or window environment. (when you set locale at installation time, you are probably setting
localectl for console / terminal input on OS’s like debian which use systemd.)
in norns, we lifted the keycode to character mapping from
evtest/kernel headers, and ported it to lua. this table effectively defines the keycode mapping by naming each keycode with a character:
if you want to help us support other keyboard locales in norns apps which handle character input, that could be done with a lua code contribution to that file or a collection of similar files for different keyboard locales. maybe this seems redunant because other apps do it, but believe it or not it appears to be the status quo and libraries like SDL have to do the same thing.
extending and swapping out the HID events table should be pretty easy to do. if you want to somehow create a virtual terminal inside the lua environment and wrap its I/O, i guess that is probably also possible, but it sounds way more difficult.
the keyboard mappings are already in the core lib - the module i just linked. look at orca source - it looks for the character input events already set up by the
hid module, like
hid.codes.KEY_SEMICOLON. this is good - only the
hid module is concerned with keycodes, the script operates on the abstraction of character-events, and we can support other locales by simply defining different code tables (or lifting them from xorg source or whatever, natch - maybe it makes sense ot make this lua module understand whatever standard file format for defining keyboard locales.)
it looks like yggrasil searches for keycodes directly, which of course will hamper any such efforts to expand locale compatibility.