Very interesting idea! I would certainly keep it in mind.
When thinking about the detailed implementation, it may
involve making keyboard drivers console aware. Or at least
we need to add interfaces between several kernel drivers --
wc, conskbd, hid. Our console driver -- wc knows who is
associated with which VT by PID, then wc needs to tell
conskbd and hid this information before any keyboard device
is opened. This really makes things more complicated.

BTW, I am currently looking into the way that our incoming
Xorg 1.5 uses keyboard devices, -- via HAL. I won't have
a very mature idea until I think things through. So I will
give you guys an update about my investigation results so that
we can figure out a best solution.

Thank you very much for the time sharing.


On 11/17/08 07:39, Edward Pilatowicz wrote:
> hey aaron,
> iirc, when the X server starts up, it registers it's pid and virtual
> terminal number with the vc subsystem, right?  if the X server did this
> before opening any keyboard/mouse devices, then when those devices are
> opened you could check who is opening them (this would probably happen
> at the same time that the redirection / re-routing for the devices
> happens), and if they are being opened by an X server assocaited with a
> virtual terminal then the vc subsystem could record this association.
> perhaps this could allow the vc subsystem automate the streams switching
> and eliminate the KIOCSDIRECT / KIOCHIDSDIRECT ioctls entirely?  just a
> thought...
> ed
> On Wed, Nov 12, 2008 at 10:23:30AM +0800, Aaron Zang wrote:
>> Hi Ed,
>> I share your thought about we'd hid as much as we can inside
>> the VT layer.
>> To detailing the situation, here is the process.
>> When Xorg is starting, it opens its keyboard device, by default
>> /dev/kbd, or specified from xorg.conf.
>> When switching to console, if the keyboard device is /dev/kbd,
>> it uses KIOCSDIRECT to direct the conskbd input to console,
>> if the keyboard is /dev/usb/hidx, it should use a KIOCHIDSDIRECT
>> to direct the hid keyboard input to conskbd.
>> When switching back, it would also use KIOCSDIRECT/KIOCHIDSDIRECT
>> with different arguments accordingly to set the input back to it.
>> I was thinking the way that we can hid the streams switching
>> inside VT is to let vtdaemon to do is job. But vtdaemon is lack
>> of the context of what/which keyboard device Xorg is using.
>> So I guess here, we'd let Xorg do its own job.
>> And the above talking is just for Xorg 1.3 and earlier. I need
>> to investigate more on 1.5.x as Alan said it relies on HAL.
>> So stay tuned ;)
>> Regards,
>> Aaron
>> On 11/11/08 08:39, Edward Pilatowicz wrote:
>>> this sounds pretty resonable to me.
>>> at first thought, it seems to me that all this should be hidden
>>> inside the vt/console/usb layer with no X interraction required.
>>> i guess i'd like some details on how you see the subsystems
>>> interracting (vt, console, Xorg, usb devices, etc) before
>>> i can provide detailed feedback.
>>> ed
>>> On Fri, Nov 07, 2008 at 05:45:30PM +0800, Aaron Zang wrote:
>>>> Hi all,
>>>> During the implementation of Xorg VT (virtual console) support,
>>>> a problem has been discovered when Xorg physically opens a USB
>>>> keyboard (/dev/usb/hid*).
>>>> By default Xorg on Solaris opens the virtual keyboard device
>>>> (/dev/kbd). The virtual keyboard (conskbd) creates two minor nodes
>>>> thus has two streams. One is the internal minor node which is linked
>>>> under console stream, the other is /dev/kbd which is for the use
>>>> of applications.
>>>> Say Xorg is running on /dev/vt/7, when /dev/vt/7 is made active,
>>>> Xorg uses KIOCSDIRECT to route conskbd IO to /dev/kbd stream.
>>>> And it will route the IO back when switching away to consoles.
>>>> HID driver creates two minor nodes for a USB keyboard too.
>>>> One minor node is internal used and the stream is plumbed under
>>>> conskbd, the other is /dev/usb/hidx.
>>>> When Xorg is configured to open /dev/usb/hidx as keyboard device,
>>>> the internal stream is unplugged from conskbd automatically.
>>>> So when switching from Xorg session back to console session, the
>>>> console will not get any input from this keyboard.
>>>> And Xorg can not close /dev/usb/hidx, since it has already dropped
>>>> the privilege and running as a normal user at this moment. If Xorg
>>>> closes /dev/usb/hidx when switching away, it loses the privilege
>>>> to reopen the keyboard device when switching back.
>>>> So the proposal here is to add a new ioctl to the hid driver for
>>>> keyboard devices which has the similar routing functionality as
>>>> KIOCSDIRECT does to conskbd driver.
>>>> Before I am preparing any official documents, I would like to
>>>> discuss it with the following purposes:
>>>> 1) Is there any existing way to resolve this?
>>>> 2) Is there any better solution?
>>>> Edward and Alan, your comments are more than welcomed.
>>>> Thanks a lot.
>>>> Aaron
>>>> --
>>>> You know some birds are not meant to be caged, their feathers are just too 
>>>> bright.
>> --
>> You know some birds are not meant to be caged, their feathers are just too 
>> bright.

You know some birds are not meant to be caged, their feathers are just too 

Reply via email to