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.


> 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 

Reply via email to