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

[Maxim Sobolev]

Maksim Yevmenkin wrote:
> [...]
> 
>>> 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"? :)

Well, since there are < /dev/console everywhere it's probably assumed 
that those commands are executed from script or the pseudo-tty.

>> 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.

But you can easily do what most other drivers do to workaround this 
problem - create separate management device node, through which it will 
be possible to inject ioctls regardless of the current state of the 
particular kbdmux instance. There are lot of such examples in the tree - 
ata(4) and md(4) drivers come into the mind instantly.

> 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.

It's funny but appears that keyboard and mouse support are going in the 
entirely opposite directions - I've seen that somebody is working on 
moving as much mouse code out of the kernel as possible. Perhaps we need 
some unified HID framework like most of the modern operating systems do?

-Maxim