On Thu, Sep 29, 2016 at 04:53:12PM +0200, Mark Kettenis wrote: > > Date: Thu, 29 Sep 2016 16:09:09 +0200 > > From: Theo Buehler <t...@math.ethz.ch> > > > > On Thu, Sep 29, 2016 at 02:19:43PM +0200, Mark Kettenis wrote: > > > This diff adds a WSKBDIO_GETENCODINGS ioctl and uses it to print a > > > list of supported encodings like the old kvm groveling code did. The > > > ioctl will clamp the number of entries that are returns to the number > > > that was passed in. This means that if the number returned is the > > > same as the number passed in, there might be more entries and you > > > probably want to retry with a larger buffer. The new implementation > > > does this. > > > > > > Waring; this did not go through a make release yet. And that might be > > > relevant, since this code gets included in the ramdisks. > > > > > > Thoughts? > > > > > > > amd64 release builds fine with this patch. I tested it on both a normal > > system and with bsd.rd, works fine. I like the fact that extended > > keyboard encodings are now also listed in bsd.rd. > > > > There is one change of behavior: previously, if a non-root user ran > > kbd -l, it would exit with status 1 and print the error message: > > > > kbd: kvm_openfiles: /dev/mem: permission denied > > > > which gave at least some indication that it must be run as root. > > > > Now it fails silently with exit code 0 without printing anything since > > opening the /dev/wskbd? devices fails, as they are owned by root:wheel > > with permissions 600. > > If you log in on the console, it actually works for non-root users as > well, at least for the primary keyboard. This is because login(1) > modifies the permissions according to /etc/fbtab. Now if you have > both pckbd(4) and ukbd(4), it will probably only show the encodings > for pckbd(4), unless you change /etc/fbtab to also change the > permissions on /dev/wskbd1. But at that point we're quickly entering > the realm where kbd(8) simply isn't the appropriate tools to manage > things. > > Now if you log in through xdm, you will in all likelyhood get an empty > list. But X has its own idea about keyboard mappings anyway. It only > initializes its settings based on the wscons settings. But it never > changes the wscons settings if you manipulate the X mappings.
Thanks for this explanation. Indeed, I only tested the old version as non-root on console. Sorry about that. Then this all makes sense. I can't comment on your choice of design, but it does read well as it is. So, fwiw, ok from me.
