> Am 24.11.2022 um 15:07 schrieb u...@disroot.org: > > Hello! > > I would like to find some supporting documentation too, if anything is > available, but for certain other reasons > (https://github.com/letoram/arcan/issues/263). Basically, this "desktop > engine" has problems with figuring out my keyboard layouts, and I want to > figure out why. This might've been more appropriate to post in ports@ but > this thread catched my eye, so I'm here. It would be nice to be able to > determine what keycodes correspond to what symbols in console, to figure out > what goes wrong in the process of how Arcan determines my keyboard layout. > Any help appreciated!
I’m not sure this will help with your issue but here is what I have been able to figure out so far: One thing that helped me a bit (though I have not solved this issue yet) was the definition of the keycodes in the USB HID standards. I found this link where presumably the codes sent by USB keyboards are defined: https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2 Or see https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf table 12 on page 53 for something more official. You will still need to figure out which keycodes a specific keyboard will send for certain keys, as there is some ambiguity with regard to the labeling of keys, especially for non-us localizations. For example some of the Apple keyboards have a <fn> modifier key. I don’t see that mentioned in the USB spec. Maybe the keyboard handles this internally but that is simply guessing at the moment. The usable entity names are somewhat defined (you need to chop off the prefix of the names) in source code: /src/sys/dev/wscons/wsksymdef.h Additionally Vlad Meșco mentioned that arbitrary Unicode values can be specified using e.g. unknown_50082 (for U+C3A2?) instead of a known entity. I have not tested this yet. The actual predefined keyboard maps are compiled into OpenBSD drivers: /src/sys/dev/pckbc/wskbdmap_mfii.c /src/sys/dev/usb/ukbdmap.c (which seems to be derived from wskbdmap_mfii.c) Note: All of the OpenBSD source files can be found at: https://cvsweb.openbsd.org That doesn’t explain the syntax of keyboard.map though. And I have analyzed the de keyboard.encoding somewhat and found it to be quite different from the way macOS treats German Apple USB keyboards. As a small experiment I tried to redefine the 7 key: wsconsctl keyboard.encoding=de wsconsctl keyboard.map+="keycode 36 = 7 slash bar backslash" Note 1: The default definition for de is "keycode 36 = 7 slash braceleft braceleft“ However the actual mapping seems to be: <7>: 7 (expected, ok) <shift><7>: / (expected, ok) <alt-left><7>: · (a small middle dot, and deleting with backspace doesn’t work) <shift><alt-left><7>: ¯ (some weird glyph with just a short horizontal line at the top, and deleting with backspace doesn’t work) <alt-right><7>: { (expected, ok) <shift><alt-right><7>: { (expected, ok) Note 2: On macOS the actual mappings are: <7>: 7 <shift><7>: / (slash) <alt><7>: | (bar) <shift><alt><7>: \ (backslash) And it does not matter whether <alt-left> or <alt-right> is used for <alt>. But this does not yield all of the expected results: <7>: 7 (expected, ok) <shift><7>: / (expected, ok) <alt-left><7>: · (a small middle dot, and deleting with backspace doesn’t work) <shift><alt-left><7>: ¯ (some weird glyph with just a short horizontal line at the top, and deleting with backspace doesn’t work) <alt-right><7>: | (expected, ok) <shift><alt-right><7>: \ (expected, ok) The <alt-left> key still does weird things. But apparently the 4 columns in the keycode entries are: <plain> <shift> <alt-right> <shift><alt-right> Note: On non-Apple keyboards <alt-right> may be labeled as <alt-gr>. Apple labels both <alt-left> and <alt-right> as <alt> and does not generally differentiate between the two. Adding the very obscure: wsconsctl keyboard.map+="keycode 226 = Cmd2 Mode_switch Multi_key" (modified from the example Vlad Meșco mentioned to match the <alt-left> keycode from the USB spec) finally yielded the expected result: <7>: 7 (expected, ok) <shift><7>: / (expected, ok) <alt-left><7>: | (expected, ok) <shift><alt-left><7>: \ (expected, ok) <alt-right><7>: | (expected, ok) <shift><alt-right><7>: \ (expected, ok) I can use this but I don’t understand how it works. :-( Putting this into /etc/wsconsctl.conf gives me a persistent modification that is one step close to my goal: # cat /etc/wsconsctl.conf # Start out with a German keyboard layout: keyboard.encoding=de # Make the <alt-left> modifier key behave the same as the <alt-right> key: keyboard.map+="keycode 226 = Cmd2 Mode_switch Multi_key" # Redefine the <7> key to match macOS: keyboard.map+="keycode 36 = 7 slash bar backslash" # More enlightened but still puzzled… Mike
