On Fri, Nov 25, 2022 at 03:32:20AM +0100, 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.
>
> ...
>
> 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
>
Hey Mike,
You can look at /usr/src/sbin/wsconsctl/map.parse.y (or browse
cvsweb.openbsd.org if you don't have sources locally). It is the yacc
file for the syntax of parsing keyboard.map statements. It's close to
BNF if you're unfamiliar with yacc, i.e. it formally describes the
grammar.
/* Parse a keyboard map. Statements are one of
*
* keysym sym1 = sym2 Assign the key containing `sym2' to
* the key containing `sym1'. This is a copy
* from the old to the new map. Therefore it
* is possible to exchange keys.
*
* keycode pos = sym ... assign the symbols to key `pos'.
* The first symbol may be a command.
* The following symbols are assigned
* to the normal and altgr groups.
* Missing symbols are generated automatically
* as either the upper case variant or the
* normal group.
*/
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.
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.
Scancodes are keyboard specific. E.g. for PC keyboard or USB keyboard,
they are pretty much listed in /usr/src/sys/dev/pckbc/wskbdmap_mfii.c .
If `wsconsctl' reports some other keyboard type for you, start
elsewhere. You might still end up in `wskbdmap_mfii.c', but that would
be a coincidence. Since I only have PCs, I cannot tell you from
experience if wsconsctl wants wskbd generic keycodes or driver specific
ones.
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).
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).
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.
Best regards,
Vlad
