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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
