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...  ;)


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.

Reply via email to