Just for fun I created a Shavian QWERTY keyboard map for #FreeBSD.
The hard part turned out to be that I had to work from pictures of layout diagrams, and tiny ones at that, cross-referencing them by eye against a Unicode chart. No-one has a text list of what Shavian alphabet characters go with what keys.
I named it gb-shaw, of course.
The #nosh Guide has a whole chapter going into a lot more detail on HID configuration; which can range at the administrator's discretion from explicitly choosing accept-all-HIDs to a strong stance on supernumerary, misbehaving, or downright malicious #HumanInputDevices.
Given that I was one of several people who proposed going this way in the 1990s, it is long past the time that recompiling one's kernel was the way to choose what #HumanInputDevices to trust.
http://jdebp.info/Softwares/nosh/guide/user-virtual-terminal-configuration.html
Just so that anyone coming across this #OpenBSD idea has any questions about the #nosh user-space virtual terminals:
In nosh uservts, USB HIDs are opt-in; whereas with most kernel VTs & X11, USB HIDs are opt-out.
The administrator has to explicitly choose (in the ways laid out in user-vt-realizer-configuration(5) which allow various combinations of address, class, and ID matching) to have a #YubiKey realized as a keyboard HID on the #uservt.
Right.
I've got Debian and FreeBSD systems with both the system and service manager running things, and a NetBSD system with just the service manager; all of the services under service management; a sprinkling of many of the #djbwares services running, including regular clock synchronization with sntpclock, dnscache, and tinydns private roots; and my test HP USB 104-key keyboard auto-connecting to the #uservt system when plugged in.
I'm running out of release blockers. (-:
There are some things that are going to be known problems with the new releases, because they'd been planned for a subsequent release back before COVID Lockdown, and I really do not want to hold up what is already years late with writing new features.
So the realizers for user-space virtual terminals will only work on dumb framebuffers for this release; because using dri was one such after-this-coming-release items.
It doesn't look quite right on a 16:9 HDMI display with a 16 by 16 font. It lacks the pixellation and CRT blurring. And the cursor is wrong. So @ColinHaynes still has the better. (-:
But it's not bad for a non-X11 framebuffer Unicode-capable terminal emulator on a #RaspberryPi running #NetBSD with the #CommodorePET and BBC character sets.
(That was the BBC font. This is the #CommodorePET font.)
The various tools from #djbwares are operational and run happily as managed services, including local DNS service, some publicfile services, and synchronizing the #RaspberryPi's clock using Bernstein's sntpclock fed into clockadd.
A #nosh user-space virtual terminal being realized onto the HDMI display of a #RaspberryPi running #NetBSD.
The realizer is console-kvt-realizer, and the framebuffer was dumped to PPM format with framebuffer-dump (to be converted to JFIF using netpbm tools). The login screen is a ttylogin@vc3-tty service, managed by service-manager, and using login-envuidgid.
Yes, it is being multiplexed with two others, and has an input method layered on top.
I have been writing doco.
https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminal-configuration.html
JdeBP