international keyboard support

[catfact]

non-US keyboard layouts are not respected by keyboard-centric scripts such as Orca. this is a norns system limitation.

norns isn't using a linux system layer (like a virtual console, Xorg or Wayland) to get symbols from the kernel. it is going directly for keycodes from the HID events stream.

scripts like Orcae make use of the named enumeration of HID codes that we made here, in the norns system HID layer:
https://github.com/monome/norns/blob/master/lua/core/hid_events.lua#L8

these enumeration names assume US keyboard layout, i think. that would probably be the best place to define other layouts for different regions; scripts could continue to use the the named enums without tracking keyboard layout.

contributions would definitely help here. IIRC the tool that made these mappings from libudev was rather ad-hoc, but i could try and clean it up and make sure it is available in the norns repo for anyone who would like to contribute other layout data.

[catfact]

maybe a better alternative: we could have matron use a virtual console (or something? not sure how to do this myself) to get symbol events from the kernel, in addition to HID events, and scripts could use either one as appropriate.

[okyeron]

Looks like the current event code mapping was created directly from the libevdev source:
https://gitlab.freedesktop.org/libevdev/libevdev/-/blob/master/include/linux/input-event-codes.h

I think we'd need to create alternate event name map tables for AZERTY/QWERTZ/etc.

Maybe something like replacing hid_events.codes with hid_events.keyboards.qwerty and then setting a default where hid_events.codes = hid_events.keyboards.qwerty but allows for an override somewhere in a preference/param?

QMK (open source keyboard software) looks like it does something similar with a keyboard map header for specific languages

I found this Google/Chrome dev update/article a very friendly way of describing what happens with the Code and Key attributes

Also FWIW - you can see what keyboard is set for linux system with cat /etc/default/keyboard
XKBLAYOUT="gb" appears to the the raspbian default?

[artfwo]

maybe a better alternative: we could have matron use a virtual console (or something? not sure how to do this myself) to get symbol events from the kernel, in addition to HID events, and scripts could use either one as appropriate.

console input will also introduce a few issues to handle:

• layout setup. on debian systems you change it by dpkg-reconfiguring keyboard-configuration and console-setup packages. this requires logging in, running some commands and answering non-trivial questions such as "what's your compose key?".
• layout switching. the default switching mechanism may not work unless the user is logged in as well, so matron might have to handle the (different) layout changing shortcuts here.

in addition to:

• character display: not all fonts in matron can display non-ASCII characters.

however, as somebody using a non-US keyboard 100% of the time, i'm wondering if this improvement is actually worth the effort. this limitation you describe has typically never been a problem in other environments - when a keyboard is used for control input (games, DAWs, vim/emacs commands) or code input. text input in native languages would be nice to have, but goes slightly beyond the purpose of norns and can be easily solved on the script level for all the potential edge cases.

[catfact]

yeah on balance it seems better to just stick with the HID codes and add new layouts there as needed. hopefully keyboard-heavy script contributors can help with this; it's as simple as you say @okyeron.

[catfact]

this topic has come up at least a couple more times so i am trying to direct interest to this issue.

one thing worth clarifying: please correct me if i'm wrong, but as i understand it the setting in /etc/default/keyboard affects only virtual console and X programs, which receive character code input from kbd.

i think we've established that the lower-hanging solution is not to implement a virtual console within matron (yuck) but to simply add more keycode tables. this could all be done in lua.

[catfact]

this might be helpful: the QMK source includes lists of aliases for many languages.
https://github.com/qmk/qmk_firmware/blob/master/quantum/keymap_extras/

one way forward would be to scrape these headers and create something that looks like, say:

hid_events.codes_colemak.KEY_P = hid_events.codes.KEY_R
...

[tyleretters]

i like the idea to add keycode tables.

"automatically detect keyboard devices" - meaning keyboards smart enough to self-identify?

[catfact]

apologies; i'm muddying the waters with what should be a new issue (or 2.)

[gonna edit this and my post above]

[tyleretters]

#1251 is beyond my skill level for now. if that seeks to "provide the keycode decoding by default" then perhaps this issue is superfluous? or would it still be valuable to do the lua conversion tables?

[catfact]

IMHO: it would still be valuable to do the lua conversion tables. i would implement new "keyboard" module as a higher-level wrapper around the existing low-level lua HID module. changes at the C level would simply facilitate choosing the appropriate script-level interface in lua for a given HID device. (e.g.: keyboard, mouse, gamepad, other.)

[tyleretters]

alright, i'll try to sketch out one table and report back for feedback

[tyleretters]

proposal:

1. configuration - @catfact floated the idea of a configuration file. i propose adding another item at the bottom of SYSTEM > DEVICES > HID which allows the user to scroll through avialable keyboard locales. only one can be selected at a time and it defaults to US-ANSI.

2. architecture / organization - similar to the qmk files, we can have one .lua file per locale. tables inside these files would be very flat and would contain the aliases.

3. usage - extend/modify keyboard to use information as defined in point 1, maps and then aliases from point 2. developers can access the output this with something like keyboard.localized(type, code, val). this will mirror (and can be used in tandem with) keyboard.event(type, code, val).

open to feedback!

[tehn]

SYSTEM > DEVICES should remain exclusively for selection.

there's already a ticket open for device-settings expansion (ie, grid rotation, midi passthru): #1129

FYI (soon) "SYSTEM" will be renamed "SETTINGS"

we could just have another submenu, or reimagine the entire SETTINGS menu system if needed

---

but generally, yes, manual selection of a list of locales which are just lua files.