cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.1

[Maksim Yevmenkin]

[...]

> > thanks for doing this! unfortunately, the sequence of command you have
> > put into the man page not entirely correct.
> >
> > it will work, if you do all the commands from the scripts and do it
> > fast enough. note that syscons(4) will try to grab the first available
> > keyboard when it does not have one, and, the first thing you do is to
> > release current keyboard.
>
> Actually I think you not quite correct - such syscons(4) behaviour is
> optional (opt in) and depends on 0x100 flags to sc(4).

yes, it depends on the flag you have mentioned and the flag is set by
default :) from GENERIC.hints

hint.sc.0.at="isa"
hint.sc.0.flags="0x100"

> At least that sequence works here with GENERIC kernel/hints just fine.

i never said it would not :) i just only pointed out that you have to
put this commands in the script. otherwise how are you going to type
after you have released the keyboard with "kbdcontrol -K"? :)

> In fact I believe the better way to handle this problem is to allow
> kbdmux(4) to be reconfigured on the fly, that is when it's already
> attached to the console. This way you will be able to attach it to the
> console first and then add/remove actual keyboards as you see fit. I
> don't think it will be very hard to do.
>
> What do you think?

that is why syscons(4) has to support KBD{ADD,DEL}KB ioctl(2)s. you
see, in order to issue ioctl(2) one must open /dev/kdbmux0 device. the
problem is that once keyboard was "kbd_allocate()"d, open(2) calls on
/dev/Xkbd will fail. so you see, once you switched keyboard to
kbdmux(4) you can not open /dev/kbdmux anymore. the only way to
reconfigure kdbmux(4) is to pass ioctl(2)s via syscons(4). just like
any other keyboard ioctl(2).

so the sequence i sent allows you to reconfigure kbdmux(4) on-the-fly.

however, all of this is really a band-aid to allow people to at least
try kbdbux(4). i have patches to syscons(4) and kbd code that will
make kbdmux(4) to automatically take over any keyboard attached to the
system. everything done in kernel. i did not commit these because
kbdmux(4) has issues that i still need to figure out and fix.

thanks,
max