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_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
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 <fn> 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 other machine to type !!.
I'm pretty sure OpenBSD doesn't have Bluetooth at this time.
However, keyboards that come with a dongle present themselves to the OS
as USB HID (same as wired ones). I don't think bluetooth keyboards are
actually that common... (I actually own one bluetooth keyboard, for an
Android tablet, and it required some searching) Oh, and I've also seen
enterprise grade wireless devices that had a bluetooth mode, but their
own dongle required a bespoke Windows driver to work. Wireless
connections are weird.
One last thing, if I understood how keyboards work in the console on
OpenBSD, I think if you have keyboards of multiple types and all of them
are connected, they all have their own settings and you need to tell the
system which one to use.
One last thing, if you have multiple keyboards, be aware that wsconsctl
has an -f flag to pick which keyboard to affect. I think
/etc/wsconsctl.conf operates on the first keyboard it detects. I could
be wrong.
Vlad
No comments:
Post a Comment