Re: Documentation of wsconsctl keyboard.map format?
Le 2 décembre 2022 05:29:33 GMT+02:00, Alexis a écrit : > >Vlad Meșco writes: > >>> 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? >> >> I mean you could add some printfs or log(9) in `wskbd.c', probably in >> `wskbd_translate', assuming control flows through there on your setup. >> >> I don't know of any utility on OpenBSD that can help here. > >xev(1)? > >https://man.openbsd.org/xev.1 > > >Alexis. Hi Alexis, At least on my i386 laptop, xev is showing different keycodes than what wscons uses. Vlad
Re: Documentation of wsconsctl keyboard.map format?
Vlad Meșco writes: 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? I mean you could add some printfs or log(9) in `wskbd.c', probably in `wskbd_translate', assuming control flows through there on your setup. I don't know of any utility on OpenBSD that can help here. xev(1)? https://man.openbsd.org/xev.1 Alexis.
Re: Documentation of wsconsctl keyboard.map format?
Le 30 novembre 2022 21:40:17 GMT+02:00, "Vlad Meșco" a écrit : >On Wed, Nov 30, 2022 at 06:17:40AM +0100, Mike Fischer wrote: >> >> Also the semantics of these is unclear to me: >> #define KS_Cmd 0xf10d >> #define KS_Cmd1 0xf10e >> #define KS_Cmd2 0xf10f > >Deep down I was hoping someone more knowledgeable would intervene and >explain them to me as well. I gave up. I think I got it. The COMMAND* modifiers are only handled in wskbd.c internal_command. As in break into ddb, switch vtty... If you have keys carryin Cmd1 and Cmd2, you need to hit both for the thing to happen (e.g. Ctrl Alt F5 to switch vtty). The single Cmd works by itself. So this is more of am FYI to the driver. Multi_key is what X calls the Compose key (e.g. Compose+~+n should give ñ; I have not tried it myself). Mode_switch is the layer above shift that gives you two more characters per key. I guess Shift+Alt_R by themselves would put you in Compose mode. And if you hold them down they are Shift+AltGr+whateverkeyyoupressed. I will probably forget this in 2 weeks' time. Vlad
Re: Documentation of wsconsctl keyboard.map format?
On Wed, Nov 30, 2022 at 06:17:40AM +0100, Mike Fischer wrote: > > 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. Mine uses `Caps_Lock'. I never thought of using anything else o_O On my i386 keyboard.map+='keysym z = y' keyboard.map+='keysym Alt_L = y' ...both work. At that precise moment I realized I needed Alt_L to get back to X :-P It would complain about Alt_L not being found if you've clobbered it via keycode assignment. But I don't know what you did before you ran that line. Maybe you did nothing wrong and that keyboard is weird. > > > > 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_key0xf109 > #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_Cmd0xf10d > #define KS_Cmd1 0xf10e > #define KS_Cmd2 0xf10f Deep down I was hoping someone more knowledgeable would intervene and explain them to me as well. I gave up. > > > > 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? I mean you could add some printfs or log(9) in `wskbd.c', probably in `wskbd_translate', assuming control flows through there on your setup. I don't know of any utility on OpenBSD that can help here. > (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 > key on some Apple keyboards are complete mysteries right now. Your method > could help solve that side of the problem. I'm pretty sure the Fn key is tied to a pin on the keyboard's controller that makes it do other stuff; the OS normally doesn't know of the existance of a Fn key. Then again, laptop UEFI's tend to have a setting to flip the logic related to F1-2-3 keys, so what do I know... > > 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. Yeah, ssh would work. Though me, I'd rather set a timeout than run over to some
Re: Documentation of wsconsctl keyboard.map format?
> Am 27.11.2022 um 19:48 schrieb Vlad Meșco : > > 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 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: >> >> Note: On non-Apple keyboards may be labeled as . Apple >> labels both and as 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 >> keycode from the USB spec) finally yielded the expected result: >> <7>: 7 (expected, ok) >> <7>: / (expected, ok) >> <7>: | (expected, ok) >> <7>: \ (expected, ok) >> <7>: | (expected, ok) >> <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_key0xf109 #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
Re: Documentation of wsconsctl keyboard.map format?
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 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: > > Note: On non-Apple keyboards may be labeled as . Apple > labels both and as 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 > keycode from the USB spec) finally yielded the expected result: > <7>: 7 (expected, ok) > <7>: / (expected, ok) > <7>: | (expected, ok) > <7>: \ (expected, ok) > <7>: | (expected, ok) > <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,
Re: Documentation of wsconsctl keyboard.map format?
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 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)
<7>: / (expected, ok)
<7>: · (a small middle dot, and deleting with backspace
doesn't work)
<7>: ¯ (some weird glyph with just a short horizontal
line at the top, and deleting with backspace doesn't work)
<7>: { (expected, ok)
<7>: { (expected, ok)
Note 2: On macOS the actual mappings are:
<7>: 7
<7>: / (slash)
<7>: | (bar)
<7>: \ (backslash)
And it does not matter whether or is used for
.
But this does not yield all of the expected results:
<7>: 7 (expected, ok)
<7>: / (expected, ok)
<7>: · (a small middle dot, and deleting with backspace
doesn't work)
<7>: ¯ (some weird glyph with just a short horizontal
line at the top, and deleting with backspace doesn't work)
<7>: | (expected, ok)
<7>: \ (expected, ok)
The key still does weird things.
But apparently the 4 columns in the keycode entries are:
Note: On non-Apple keyboards may be labeled as .
Apple labels both and as 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
keycode from the USB spec) finally yielded the expected result:
<7>: 7 (expected, ok)
<7>: / (expected, ok)
<7>: | (expected, ok)
<7>: \ (expected, ok)
<7>: | (expected, ok)
<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 modifier key behave the same as the
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!
Re: Documentation of wsconsctl keyboard.map format?
> 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 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)
<7>: / (expected, ok)
<7>: · (a small middle dot, and deleting with backspace doesn’t work)
<7>: ¯ (some weird glyph with just a short horizontal line at
the top, and deleting with backspace doesn’t work)
<7>: { (expected, ok)
<7>: { (expected, ok)
Note 2: On macOS the actual mappings are:
<7>: 7
<7>: / (slash)
<7>: | (bar)
<7>: \ (backslash)
And it does not matter whether or is used for .
But this does not yield all of the expected results:
<7>: 7 (expected, ok)
<7>: / (expected, ok)
<7>: · (a small middle dot, and deleting with backspace doesn’t work)
<7>: ¯ (some weird glyph with just a short horizontal line at
the top, and deleting with backspace doesn’t work)
<7>: | (expected, ok)
<7>: \ (expected, ok)
The key still does weird things.
But apparently the 4 columns in the keycode entries are:
Note: On non-Apple keyboards may be labeled as . Apple
labels both and as 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 keycode
from the USB spec) finally yielded the expected result:
<7>: 7 (expected, ok)
<7>: / (expected, ok)
<7>: | (expected, ok)
<7>: \ (expected, ok)
<7>: | (expected, ok)
<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 modifier key behave the same as the 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
Re: Documentation of wsconsctl keyboard.map format?
On 2022-11-23 02:21, Mike Fischer wrote: > Am 23.11.2022 um 11:43 schrieb Vlad Meșco : > > On Wed, Nov 23, 2022 at 06:57:17AM +, Jason McIntyre wrote: > > On Wed, Nov 23, 2022 at 12:21:26AM +0100, Mike Fischer wrote: > > > keyboard.encoding=us > keyboard.map+="keysym Caps_Lock = Control_L" > mouse.tp.tapping=3 > mouse.reverse_scrolling=1 > keyboard.map+="keysym Caps_Lock = Control_L" Duplicate? ...probably. > keyboard.map+="keycode 184 = Cmd2 Mode_switch Multi_key" I don't think I understand what this actually does? In my case, maps right alt to AltGr. I don't remember exactly how it works, but I \ think CmdN tells the driver it's a modifier and the next N tokens tell it what. First of all none of my ‚keyboard.map's have a keycode 184. I tried \ keyboard.encoding=us, keyboard.encoding=de, keyboard.encoding=fr, \ keyboard.encoding=fr.apple. I don't know, there might be differences between PC, USB and Apple. I mentioned HU \ earlier because that definitely has altgr defined. Second, if the columns normally represent levels (or layers), how does that work \ here? Plain 184 is Cmd2; 184 + some modifier is Mode_switch; and 184 + some other \ modifier is Multi_key (whatever that is supposed to mean)? > # use ? for unicode that causes mojibake > keyboard.map+="keycode 26 = question question bracketleft braceleft" > keyboard.map+="keycode 27 = question question bracketright braceright" > keyboard.map+="keycode 39 = question question semicolon colon" > keyboard.map+="keycode 40 = question question apostrophe quotedbl" > keyboard.map+="keycode 41 = question question grave asciitilde" # 3byte UTF-8, \ > don't bother keyboard.map+="keycode 43 = question question backslash bar" > keyboard.map+="keycode 51 = comma semicolon less question" > keyboard.map+="keycode 52 = period colon greater question" > > A more proper example for e.g. keycode 26: > > keyboard.map+="keycode 26 = abreve Abreve bracketleft braceleft" > > Or for keys that don't have a symbolic name: > > keyboard.map+="keycode 43 = unknown_50082 unknown_50050 backslash bar" > > I started from US which is 90% there, and the first thing is to add > right Alt as `Mode_switch', otherwise it's just (left) Alt (which I > think just sets the MSB, IDK; you want AltGr/Mode_switch if you want to > map specific characters). > > Which keycode is what? I don't know. I dumped the hu layout as a > reference with `doas wsconsctl keyboard.map > hu.map' and looked at what > was done for that crazy layout, and started from there. > > Cheers, > Vlad Thanks, that helps somewhat. It still is strange to have to resort to experiments \ to figure things out instead of having them documented on OpenBSD. By xkb do you mean xkeyboard-config(7)? I have looked at the man page but I \ honestly can't see much similarity to the keyboard.map syntax. I also looked at \ setxkbmap(1) and xkbcomp(1) but they where no help either. I don't normally use X \ for anything so I am not very familiar with all of the associated settings. https://www.x.org/wiki/XKB/ did seem to explain some relevant concepts though. For \ example the concept of levels which probably translates to the columns used in the \ keycode statements? But where are the definitions of which modifier (or combination \ thereof) selects which column? 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!
Re: Documentation of wsconsctl keyboard.map format?
Le 24 novembre 2022 04:12:43 GMT+02:00, Mike Fischer a écrit : > >> Am 23.11.2022 um 11:43 schrieb Vlad Meșco : >> >> On Wed, Nov 23, 2022 at 06:57:17AM +, Jason McIntyre wrote: >>> On Wed, Nov 23, 2022 at 12:21:26AM +0100, Mike Fischer wrote: >> >> >>keyboard.encoding=us >>keyboard.map+="keysym Caps_Lock = Control_L" >>mouse.tp.tapping=3 >>mouse.reverse_scrolling=1 >>keyboard.map+="keysym Caps_Lock = Control_L“ > >Duplicate? ...probably. > >>keyboard.map+="keycode 184 = Cmd2 Mode_switch Multi_key“ > >I don’t think I understand what this actually does? > In my case, maps right alt to AltGr. I don't remember exactly how it works, but I think CmdN tells the driver it's a modifier and the next N tokens tell it what. >First of all none of my ‚keyboard.map's have a keycode 184. I tried >keyboard.encoding=us, keyboard.encoding=de, keyboard.encoding=fr, >keyboard.encoding=fr.apple. > I don't know, there might be differences between PC, USB and Apple. I mentioned HU earlier because that definitely has altgr defined. >Second, if the columns normally represent levels (or layers), how does that >work here? Plain 184 is Cmd2; 184 + some modifier is Mode_switch; and 184 + >some other modifier is Multi_key (whatever that is supposed to mean)? > > >># use ? for unicode that causes mojibake >>keyboard.map+="keycode 26 = question question bracketleft braceleft" >>keyboard.map+="keycode 27 = question question bracketright braceright" >>keyboard.map+="keycode 39 = question question semicolon colon" >>keyboard.map+="keycode 40 = question question apostrophe quotedbl" >>keyboard.map+="keycode 41 = question question grave asciitilde" # 3byte >> UTF-8, don't bother >>keyboard.map+="keycode 43 = question question backslash bar" >>keyboard.map+="keycode 51 = comma semicolon less question" >>keyboard.map+="keycode 52 = period colon greater question" >> >> A more proper example for e.g. keycode 26: >> >>keyboard.map+="keycode 26 = abreve Abreve bracketleft braceleft" >> >> Or for keys that don't have a symbolic name: >> >>keyboard.map+="keycode 43 = unknown_50082 unknown_50050 backslash bar" >> >> I started from US which is 90% there, and the first thing is to add >> right Alt as `Mode_switch', otherwise it's just (left) Alt (which I >> think just sets the MSB, IDK; you want AltGr/Mode_switch if you want to >> map specific characters). >> >> Which keycode is what? I don't know. I dumped the hu layout as a >> reference with `doas wsconsctl keyboard.map > hu.map' and looked at what >> was done for that crazy layout, and started from there. >> >> Cheers, >> Vlad > >Thanks, that helps somewhat. It still is strange to have to resort to >experiments to figure things out instead of having them documented on OpenBSD. > >By xkb do you mean xkeyboard-config(7)? I have looked at the man page but I >honestly can’t see much similarity to the keyboard.map syntax. I also looked >at setxkbmap(1) and xkbcomp(1) but they where no help either. I don’t normally >use X for anything so I am not very familiar with all of the associated >settings. > >https://www.x.org/wiki/XKB/ did seem to explain some relevant concepts though. >For example the concept of levels which probably translates to the columns >used in the keycode statements? But where are the definitions of which >modifier (or combination thereof) selects which column? > It's usually the same 4, plain, shift, altgr, altgr+shift. The source for pckbc calls them such. https://cvsweb.openbsd.org/src/sys/dev/pckbc/wskbdmap_mfii.c?rev=1.47=text/x-cvsweb-markup > >I gather the built-in maps for e.g. us, de, fr.apple, etc. are actually >compiled into some code, not config files somwhere on disk? Yes, part of pckbc, usb keyboard (derived from the PC one) and Apple ADB. See usr/src/sys/dev/pckbc/wskbdmap_mfii, dev/usb/uwskbmap, dev/adb. Technically you can fully define them with wsconsctl by stating out each keycode (I think this is called custom or user). > > >Thanks! >Mike
Re: Documentation of wsconsctl keyboard.map format?
> Am 23.11.2022 um 11:43 schrieb Vlad Meșco : > > On Wed, Nov 23, 2022 at 06:57:17AM +, Jason McIntyre wrote: >> On Wed, Nov 23, 2022 at 12:21:26AM +0100, Mike Fischer wrote: >>> Hi! >>> >>> I???m trying to use a German Apple Mac keyboard with OpenBSD 7.2 and I???d >>> like to match the mapping to that of macOS. >>> >>> `wsconsctl keyboard.encoding=de` helps, but several mappings are >>> different/missing. For example the pipe character | should be alt-7 but >>> isn???t. Mostly the alt-combinations are missing or wrong. >>> >>> So I thought I could use keyboard.map settings to correct this. But I >>> can???t find any documentation of the format ??? very unusual for OpenBSD. >>> >>> Did I miss something? >>> >>> Can someone point me to the documentation please? >>> >>> Thanks! >>> >>> Mike >>> >> >> hi. >> >> maybe you are looking for wsksymdef.h: >> >>WSCONSCTL(8) System Manager's Manual WSCONSCTL(8) >> >> ... >> >> Modify the current keyboard encoding so that, when the Caps >> Lock key is pressed, the same encoding sequence as Left >> Control is sent. For a full list of keysyms, and keycodes, >> refer to the /usr/include/dev/wscons/wsksymdef.h file. >> >> # wsconsctl keyboard.map+="keysym Caps_Lock = >> Control_L" >> >> jmc >> > > Hey, > > If it helps, here's my wsconsctl.conf to add some Romanian keyboard > bindings in the console for keys which are behind AltGr. Note, I've > intentionally made some Romanian specific unicode characters output > a literal `?' since they're not very usable in wscons. > > You can either use symbolic names (from wsksymdef.h) or use stuff like > `unknown_51355' to give it a U+code point in decimal form. For German, > you probably have everything you need in wsksymdef.h. Note, the format > is also very similar to xkb; originally I thought they were the same > (they aren't 100% the same). > > >keyboard.encoding=us >keyboard.map+="keysym Caps_Lock = Control_L" >mouse.tp.tapping=3 >mouse.reverse_scrolling=1 >keyboard.map+="keysym Caps_Lock = Control_L“ Duplicate? >keyboard.map+="keycode 184 = Cmd2 Mode_switch Multi_key“ I don’t think I understand what this actually does? First of all none of my ‚keyboard.map's have a keycode 184. I tried keyboard.encoding=us, keyboard.encoding=de, keyboard.encoding=fr, keyboard.encoding=fr.apple. Second, if the columns normally represent levels (or layers), how does that work here? Plain 184 is Cmd2; 184 + some modifier is Mode_switch; and 184 + some other modifier is Multi_key (whatever that is supposed to mean)? ># use ? for unicode that causes mojibake >keyboard.map+="keycode 26 = question question bracketleft braceleft" >keyboard.map+="keycode 27 = question question bracketright braceright" >keyboard.map+="keycode 39 = question question semicolon colon" >keyboard.map+="keycode 40 = question question apostrophe quotedbl" >keyboard.map+="keycode 41 = question question grave asciitilde" # 3byte > UTF-8, don't bother >keyboard.map+="keycode 43 = question question backslash bar" >keyboard.map+="keycode 51 = comma semicolon less question" >keyboard.map+="keycode 52 = period colon greater question" > > A more proper example for e.g. keycode 26: > >keyboard.map+="keycode 26 = abreve Abreve bracketleft braceleft" > > Or for keys that don't have a symbolic name: > >keyboard.map+="keycode 43 = unknown_50082 unknown_50050 backslash bar" > > I started from US which is 90% there, and the first thing is to add > right Alt as `Mode_switch', otherwise it's just (left) Alt (which I > think just sets the MSB, IDK; you want AltGr/Mode_switch if you want to > map specific characters). > > Which keycode is what? I don't know. I dumped the hu layout as a > reference with `doas wsconsctl keyboard.map > hu.map' and looked at what > was done for that crazy layout, and started from there. > > Cheers, > Vlad Thanks, that helps somewhat. It still is strange to have to resort to experiments to figure things out instead of having them documented on OpenBSD. By xkb do you mean xkeyboard-config(7)? I have looked at the man page but I honestly can’t see much similarity to the keyboard.map syntax. I also looked at setxkbmap(1) and xkbcomp(1) but they where no help either. I don’t normally use X for anything so I am not very familiar with all of the associated settings. https://www.x.org/wiki/XKB/ did seem to explain some relevant concepts though. For example the concept of levels which probably translates to the columns used in the keycode statements? But where are the definitions of which modifier (or combination thereof) selects which column? I gather the built-in maps for e.g. us, de, fr.apple, etc. are actually compiled into some code, not config files somwhere on disk? Thanks! Mike
Re: Documentation of wsconsctl keyboard.map format?
> Am 23.11.2022 um 07:57 schrieb Jason McIntyre : > > On Wed, Nov 23, 2022 at 12:21:26AM +0100, Mike Fischer wrote: >> Hi! >> >> I???m trying to use a German Apple Mac keyboard with OpenBSD 7.2 and I???d >> like to match the mapping to that of macOS. >> >> `wsconsctl keyboard.encoding=de` helps, but several mappings are >> different/missing. For example the pipe character | should be alt-7 but >> isn???t. Mostly the alt-combinations are missing or wrong. >> >> So I thought I could use keyboard.map settings to correct this. But I >> can???t find any documentation of the format ??? very unusual for OpenBSD. >> >> Did I miss something? >> >> Can someone point me to the documentation please? >> >> Thanks! >> >> Mike >> > > hi. > > maybe you are looking for wsksymdef.h: > >WSCONSCTL(8)System Manager's Manual WSCONSCTL(8) > > ... > >Modify the current keyboard encoding so that, when the Caps >Lock key is pressed, the same encoding sequence as Left >Control is sent. For a full list of keysyms, and keycodes, >refer to the /usr/include/dev/wscons/wsksymdef.h file. > > # wsconsctl keyboard.map+="keysym Caps_Lock = > Control_L" > > jmc Yes, I did look at the source but wasn’t sure about the implications. I gather that removing the KS_ or K*_L*_ prefix from the defines yields the entities I can use for wsconsctl. Ok, that helps somewhat. I’m still confused about the 2-4 columns in the keycode = <1> <2> <3> <4> syntax. No documentation insight for that, AFAICT. The first 2 seem to be . But what are the last two columns? `wsconsctl keyboard.map` does not seem to show show all keycodes. For the de layout the first entry is 'keycode 4 = a A‘. What about keycode 1-3 (or 0-3 depending on where the values start)? Maybe that is normal because keyboards don’t actually use all keycodes? Who knows? And some Apple keyboards also have an key which acts as a modifier. I don’t see that mentioned anywhere. Or is that the KS_Mode_switch? Thanks for your help! Mike
Re: Documentation of wsconsctl keyboard.map format?
On Wed, Nov 23, 2022 at 06:57:17AM +, Jason McIntyre wrote: > On Wed, Nov 23, 2022 at 12:21:26AM +0100, Mike Fischer wrote: > > Hi! > > > > I???m trying to use a German Apple Mac keyboard with OpenBSD 7.2 and I???d > > like to match the mapping to that of macOS. > > > > `wsconsctl keyboard.encoding=de` helps, but several mappings are > > different/missing. For example the pipe character | should be alt-7 but > > isn???t. Mostly the alt-combinations are missing or wrong. > > > > So I thought I could use keyboard.map settings to correct this. But I > > can???t find any documentation of the format ??? very unusual for OpenBSD. > > > > Did I miss something? > > > > Can someone point me to the documentation please? > > > > Thanks! > > > > Mike > > > > hi. > > maybe you are looking for wsksymdef.h: > > WSCONSCTL(8) System Manager's Manual WSCONSCTL(8) > > ... > >Modify the current keyboard encoding so that, when the Caps >Lock key is pressed, the same encoding sequence as Left >Control is sent. For a full list of keysyms, and keycodes, >refer to the /usr/include/dev/wscons/wsksymdef.h file. > > # wsconsctl keyboard.map+="keysym Caps_Lock = > Control_L" > > jmc > Hey, If it helps, here's my wsconsctl.conf to add some Romanian keyboard bindings in the console for keys which are behind AltGr. Note, I've intentionally made some Romanian specific unicode characters output a literal `?' since they're not very usable in wscons. You can either use symbolic names (from wsksymdef.h) or use stuff like `unknown_51355' to give it a U+code point in decimal form. For German, you probably have everything you need in wsksymdef.h. Note, the format is also very similar to xkb; originally I thought they were the same (they aren't 100% the same). keyboard.encoding=us keyboard.map+="keysym Caps_Lock = Control_L" mouse.tp.tapping=3 mouse.reverse_scrolling=1 keyboard.map+="keysym Caps_Lock = Control_L" keyboard.map+="keycode 184 = Cmd2 Mode_switch Multi_key" # use ? for unicode that causes mojibake keyboard.map+="keycode 26 = question question bracketleft braceleft" keyboard.map+="keycode 27 = question question bracketright braceright" keyboard.map+="keycode 39 = question question semicolon colon" keyboard.map+="keycode 40 = question question apostrophe quotedbl" keyboard.map+="keycode 41 = question question grave asciitilde" # 3byte UTF-8, don't bother keyboard.map+="keycode 43 = question question backslash bar" keyboard.map+="keycode 51 = comma semicolon less question" keyboard.map+="keycode 52 = period colon greater question" A more proper example for e.g. keycode 26: keyboard.map+="keycode 26 = abreve Abreve bracketleft braceleft" Or for keys that don't have a symbolic name: keyboard.map+="keycode 43 = unknown_50082 unknown_50050 backslash bar" I started from US which is 90% there, and the first thing is to add right Alt as `Mode_switch', otherwise it's just (left) Alt (which I think just sets the MSB, IDK; you want AltGr/Mode_switch if you want to map specific characters). Which keycode is what? I don't know. I dumped the hu layout as a reference with `doas wsconsctl keyboard.map > hu.map' and looked at what was done for that crazy layout, and started from there. Cheers, Vlad
Re: Documentation of wsconsctl keyboard.map format?
On Wed, Nov 23, 2022 at 12:21:26AM +0100, Mike Fischer wrote: > Hi! > > I???m trying to use a German Apple Mac keyboard with OpenBSD 7.2 and I???d > like to match the mapping to that of macOS. > > `wsconsctl keyboard.encoding=de` helps, but several mappings are > different/missing. For example the pipe character | should be alt-7 but > isn???t. Mostly the alt-combinations are missing or wrong. > > So I thought I could use keyboard.map settings to correct this. But I can???t > find any documentation of the format ??? very unusual for OpenBSD. > > Did I miss something? > > Can someone point me to the documentation please? > > Thanks! > > Mike > hi. maybe you are looking for wsksymdef.h: WSCONSCTL(8) System Manager's Manual WSCONSCTL(8) ... Modify the current keyboard encoding so that, when the Caps Lock key is pressed, the same encoding sequence as Left Control is sent. For a full list of keysyms, and keycodes, refer to the /usr/include/dev/wscons/wsksymdef.h file. # wsconsctl keyboard.map+="keysym Caps_Lock = Control_L" jmc
Documentation of wsconsctl keyboard.map format?
Hi! I’m trying to use a German Apple Mac keyboard with OpenBSD 7.2 and I’d like to match the mapping to that of macOS. `wsconsctl keyboard.encoding=de` helps, but several mappings are different/missing. For example the pipe character | should be alt-7 but isn’t. Mostly the alt-combinations are missing or wrong. So I thought I could use keyboard.map settings to correct this. But I can’t find any documentation of the format — very unusual for OpenBSD. Did I miss something? Can someone point me to the documentation please? Thanks! Mike
