On 2022-11-25 05:32, Mike Fischer wrote:
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
Thank you! This helps to figure out a part the picture of how these
specific keys are handled. If you find anything else which might be of
use, please share! The same applies to me, if I will figure out
something I will certainly share it here. Maybe, some diffs to document
this behaviour will be produced in the end!
