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.
