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 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 >> bright. -- You know some birds are not meant to be caged, their feathers are just too bright.
