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
