[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
On 11/17/08 12:46, Edward Pilatowicz wrote: > yeah, it just an idea, and you know me, i'm a dreamer... ;) i keep > thinking that if more of this was handled by the kernel the when the X > server hangs we could still switch terminals to debug it. course this > would also depend on the kernel being able to switch from graphics to > text modes, and if we had that then my dream of being able to drop to > kmdb upon request or panic would also be possible. of course your > probably sick of hearing me ask for that feature... ;) hehe,:) I share your eagerness to this feature. I personally have done some investigation on it since it is required by so many people. Our keyboard/console state is relatively a small piece of the chunk. The fatal thing is that the kernel is not aware of the 2D graphic context which is maintained by Xorg. I even tried to reinitialize the graphic hardware to VGA text mode after Xorg crashed, but it only worked in the condition that Xorg is using its VGA ddx driver. I probably have mentioned that to you before ;). I'd like to make our changes align with our final dream ;) so I would keep it in mind. And thanks for reminding me this. Regards, Aaron > > ed > > On Mon, Nov 17, 2008 at 10:01:45AM +0800, Aaron Zang wrote: >> Ed, >> 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. >> >> Aaron >> >> 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 l
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
Ed, 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. Aaron 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 m
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
yeah, it just an idea, and you know me, i'm a dreamer... ;) i keep thinking that if more of this was handled by the kernel the when the X server hangs we could still switch terminals to debug it. course this would also depend on the kernel being able to switch from graphics to text modes, and if we had that then my dream of being able to drop to kmdb upon request or panic would also be possible. of course your probably sick of hearing me ask for that feature... ;) ed On Mon, Nov 17, 2008 at 10:01:45AM +0800, Aaron Zang wrote: > Ed, > 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. > > Aaron > > 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 a
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
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.
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
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.
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
Alan, Thanks for the info. Please see below. On 11/11/08 01:27, Alan Coopersmith wrote: > Aaron Zang wrote: >> By default Xorg on Solaris opens the virtual keyboard device >> (/dev/kbd). > > ...in Xorg 1.3 and earlier. In the Xorg 1.5.x release we're working > to integrate now, Xorg uses HAL to discover input devices and gets > back the individual HID devices from under /dev/usb, so that device > events can be handled separately by applications, and device configurations > such as 3rd-button-emulation or keyboard layout can be set per-physical > device. > What does Xorg 1.5.x do when there is no USB keyboard on the system? Would it still use /dev/kbd to access say a PS/2 keyboard? I will investigate on this issue. Thanks again, Aaron -- You know some birds are not meant to be caged, their feathers are just too bright.
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
Aaron Zang wrote: > Alan, > Thanks for the info. > Please see below. > > On 11/11/08 01:27, Alan Coopersmith wrote: >> Aaron Zang wrote: >>> By default Xorg on Solaris opens the virtual keyboard device >>> (/dev/kbd). >> >> ...in Xorg 1.3 and earlier. In the Xorg 1.5.x release we're working >> to integrate now, Xorg uses HAL to discover input devices and gets >> back the individual HID devices from under /dev/usb, so that device >> events can be handled separately by applications, and device >> configurations >> such as 3rd-button-emulation or keyboard layout can be set >> per-physical device. >> > > What does Xorg 1.5.x do when there is no USB keyboard on the system? > Would it still use /dev/kbd to access say a PS/2 keyboard? That's a good question - the USB team in Beijing will have to tell us what device HAL passes up in that case. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
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.
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
Aaron Zang wrote: > By default Xorg on Solaris opens the virtual keyboard device > (/dev/kbd). ...in Xorg 1.3 and earlier. In the Xorg 1.5.x release we're working to integrate now, Xorg uses HAL to discover input devices and gets back the individual HID devices from under /dev/usb, so that device events can be handled separately by applications, and device configurations such as 3rd-button-emulation or keyboard layout can be set per-physical device. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
[vconsole-discuss] New ioctl to route IO between the two streams of one USB keyboard
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.
