Date: Thu, 29 Dec 2005 14:13:04 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Maxim.Sobolev@portaone.com Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.1 Message-ID: <bb4a86c70512291413g6a3f6952g7c3f26b1951fff9c@mail.gmail.com> In-Reply-To: <43B45653.5050606@portaone.com> References: <200512292011.jBTKBkVa073791@repoman.freebsd.org> <bb4a86c70512291324y7a12ba62qd9a1713cfe53a386@mail.gmail.com> <43B45653.5050606@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[...]
> > 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=3D"isa"
hint.sc.0.flags=3D"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70512291413g6a3f6952g7c3f26b1951fff9c>