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.

Reply via email to