> Am 27.11.2022 um 19:48 schrieb Vlad Meșco <vlad.mesco@gmail.com>:
>
> On Fri, Nov 25, 2022 at 03:32:20AM +0100, Mike Fischer wrote:
>>
>>> Am 24.11.2022 um 15:07 schrieb unix@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.
>>
>> ...
>>
>> 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. :-(
>>
>> ...
>>
>> More enlightened but still puzzled…
>> Mike
>>
Hi Vlad,
thanks and sorry for the late reply. I was dealing with other things and getting the Apple keyboard working like I expect is more of a hobby project…
> Hey Mike,
>
> You can look at /usr/src/sbin/wsconsctl/map.parse.y
Good idea! I'll take a look.
One thing I did notice was that the keysym examples I saw in the (sparse) documentation did not work. For example:
# wsconsctl keyboard.map+="keysym Alt_L = Alt_R"
wsconsctl: keysym Alt_L not found
#
Actually none of the keyboard.map versions I have seen so far use keysym.
> As mentioned earlier, the keysyms and commands and groups are listed in
> /usr/src/sys/dev/wscons/wsksymdef.h . Around line 485 you get into
> modifiers, function keys, and command keys.
I saw that. Most of the modifier keys are self-explanatory. However I have no idea what
#define KS_Multi_key 0xf109
#define KS_Mode_switch 0xf10a
mean? And they are used in the keyboard maps for the definitions of the Alt keys:
keycode 230 = Cmd2 Mode_switch Multi_key
And my patch/setting to make the left Alt key behave the same as the right one:
keycode 226 = Cmd2 Mode_switch Multi_key
Also the semantics of these is unclear to me:
#define KS_Cmd 0xf10d
#define KS_Cmd1 0xf10e
#define KS_Cmd2 0xf10f
> For educational purposes, you can go check /usr/src/sbin/wsconsctl,
> where e.g. util.c lists keyboard types. Another place is
> /usr/include/dev/wscons/wsconsio.h which also lists what tokens
> wsconsctl likes. The wscons driver is in /usr/src/sys/dev/wscons (also,
> man 8 wskbd), and keyboard drivers are also thereabout (man -k kbd &&
> man -k kbc). You can check `wsconsctl keyboard.type' to see what you
> have, then check that driver for scancodes.
Right. I have already looked at much of that.
> Scancodes are keyboard specific.
As witnessed by the difference between your solution for mapping the left Alt key to the same function as the right one, vs. mine.
> If that's not enough, you can start assigning [0-9a-zA-Z] to sequential
> keycodes from e.g. 0-255 and start noting down what's what. This might
> help with random extra keys (e.g. a physical volume up/down pair of keys
> which cannot be builtin as it's hard to predict what keys exist and what
> what the silkscreen says). You probably want to run something stupid
> like `sleep 300 && wsconsctl keyboard.encoding=us &' before doing that,
> though, as you'll probably clobber uparrow, CTRL+R, vtty switch or any
> other key that you could use to "get back" to a normal state. What I'm
> saying is use a script that sets up a timed reset and does a batch of
> mappings (e.g. 62 at a time).
Good idea! I may try that. It would be too much to hope for a setting that logs keycodes to some log file or to the console I expect?
(Misused that would be a potential security problem. But with proper access rights and no persistence across reboots it could help _map_ a keyboard.)
Many of the keycodes are fairly easy to figure out, given the keyboard.map and the results of pressing the keys. Ambiguity remains for some keys where multiple keycodes lead to the same character. And other keys like the <fn> key on some Apple keyboards are complete mysteries right now. Your method could help solve that side of the problem.
To get back to a normal setting I think an ssh session may also work. My current working hypotheses is that the keyboard.map is only relevant when using a physically connected (or Bluetooth if OpenBSD supports that) keyboard. Otherwise ssh would need to send keycodes which I am fairly certain it doesn't.
> Lastly, for educational purposes, you can cross check what X11 did to
> support keyboards (xkbmap and xmodmap); concepts listed there such as
> levels, modifiers, compose sequences, what each modifier is supposed to
> do etc, still apply here (though there might not be much to cut-paste).
Certainly interesting but I don't think that will help solve my open questions.
> I do not feel I have the competence to explain the 47000 keyboard
> modifiers that UNIX has known over the years, so by all means, look at
> historic UNIX documentation, look at X11 documentation, look through
> OpenBSD's sources, look through mailing list archives, talk to friends,
> look on wikipedia what keyboard the early authors of Emacs were using,
> and so on and so forth. At some point you'll find your Bodhi tree and it
> will all make sense. Hint: it's mostly a mess. I have no key labelled
> "Meta" on any of my keyboards, yet I use that key all the time. What is
> Meta? IDK, some key a lot of manpages tell me to use; I found it one
> day, I've been using it ever since. We're friends now.
Nah, while the history is very likely fascinating, I'm more interested in a practical solution at the moment.
Still, thank you very much for your help!
Mike
No comments:
Post a Comment