On 06/05/09 15:52, Edward Pilatowicz wrote: > On Fri, Jun 05, 2009 at 03:09:23PM +0800, Aaron Zang wrote: >> Hi Ed, >> >> I think we are missing some points here. > > it's quite likely that i'm missing a lot of points, so please be patient > with me. > >> The hid (or other devices) are not only associated to VTs. >> If these devices are exclusively for console uses, it would >> be great to bind them to VTs. >> But how about other appliations which access these devices >> with no regard to console? >> > > other apps wouldn't issue the binding ioctl, so they would have > exclusive access to the device, regardless of vt switching. just the > way it works today. >
Other applications may share the same devices with Xorg which are bind to certain VT by Xorg. > do you have any specific examples of these types of applications and how > they work? > No. But occasionally I need to "cat /dev/usb/hid0" to see if my keyboard is still working. If a user does that on purpose, he probably won't want to lose input, especially for a long time. That might not be a very proper example. Just the idea of Xorg binding shared devices to VTs seems very weird to me. >> Say Xorg opens /dev/usb/hid0, and then a privileged application >> opens /dev/usb/hid0 and starts to read. If switched back to console, >> input will be switched to the internal stream silently. >> The user application may starve if never switching back. >> At least with the HIDIOC[GS]IOCTLS the user application may switch >> the input back. >> > > can you provide an example of this case? > > it seems to me that if both X and the privileged app try to read from > the same stream at the same time, the results will be non-deterministic. > (X may get some data and the app may get other bits.) how does this > work today? > Yes, if they are both reading the results will be non-deterministic. When switched away, Xorg may not be reading input, though it still keeps the file open, but the other application may still reading. Even when Xorg is active, it polls the input devices, so if there are other applications reading the same input device, the input would likely be read by the application. I tried "/dev/usb/hid0" in my gnome terminal, it seems this thread gets all the input since the characters echoed on the terminal is not recognizable. > also, do you really expect applications (other than X) to be > HIDIOC[GS]IOCTLS aware? if the X server switches intput away from the > app with HIDIOCSIOCTLS, how will the app detect that it should be > issuing a HIDIOC[GS]IOCTLS to switch back? also, if the application did > this wouldn't X also start recieving data again as well? > My thoughts are if we switch streams automatically during switch if would be UNFAIR for other applications not be able to switch them back. There might not be any existing well known applications do that, but we can not rule out the possibility, especially in the future. The application could set up a timer, if it expires, it could check the direction and if switched away, switched back, it is privileged application, it could do anything it likes. >> The real problem resulting in the Solaris specific code in handling >> switch in Xorg is because our console/hid... devices are STREAMS >> based, if they are normal character devices, there won't be any >> differences. >> > > really? i thought the problem was an issue of deciding which consumer > of a keyboard/mouse (say console subsystem or an X session) is active, > and hence which device consumer should actually be recieving input from > the device. is my understanding of the problem correct? if so, how is > this decision affected by the device type (streams vs normal character > device). > If not STREAMS based, you do not need to switch streams. Just stop reading the input devices if switched away. Regards, Aaron > ed > >> Regards, >> Aaron >> >> >> On 06/05/09 14:11, Edward Pilatowicz wrote: >>> On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: >>>> Hey Ed, >>>> >>>> Yes, as you said, we've descended into design review again. ;) I guess >>>> it's because these fast changes/features in Xorg were not foreseeable >>>> during the initial design. >>>> >>>> Your philosophy of more simple interface between the application and >>>> the kernel is what I have been seeking. >>>> Here is some of my primary thoughts on what you pointed out. Please advise. >>>> >>>> 1) The HID streams switch ioctls are still needed, even though within >>>> the kernel. >>>> If the kernel knows which hid device is related to which VT, it >>>> (console) >>>> still need to tell the hid driver to switch streams when necessary. >>>> >>> sure, but then those redirection ioctls are then private kernel >>> interfaces that the xserver doesn't need to know about them. (there by >>> simplifying the xserver and requiring less solaris specific code within >>> the xserver.) >>> >>>> 2) The following is the current architecture digram. >>>> Letting console know about the information in hid level sounds bad to >>>> me. >>>> The other option is to let conskbd maintain the info of which hid device >>>> is related to which VT. This would result in conskbd knowing about >>>> console/VT details. Still not good. >>>> >>>> >>>> +---------+ | | >>>> | console | | | >>>> +----+----+ | | >>>> | | | >>>> | | | >>>> +-+-------+--+ | >>>> | conskbd | | >>>> +--------+---+ | >>>> | | >>>> | | >>>> +-+---------+--+ >>>> | hid | >>>> +--------------+ >>>> >>> why doesn't the VT subsystem keep track of which devices are associated >>> with a given VT? >>> >>> if a hid device get's a "vt bind" ioctl it could invoke some VT callback >>> function that tracks the binding/association. then when the VT >>> subsystem get's a request to switch VTs, it could redirect io as needed. >>> >>>> 3) Say Xorg registers which input device it's using during start up to >>>> the kernel, and upon receiving that ioctl, the kernel (either console >>>> or conskbd) set up a list of input devices for each VT. What if >>>> Xorg gets killed and does not have the chance to issue the ioctl to >>>> inform the kernel to free the list? >>>> Yes, every opened file would be closed, it could be the hid driver >>>> tell the list maintainer to update, would it involve complex interfaces >>>> between the 3 components -- console/conskbd/hid? >>>> >>>> >>> this would need to be managed in two ways. >>> >>> first, if a VT is closed (which is what would presumably happen if the >>> X server died), then all device bindings for that VT are torn down. >>> >>> second, whenever a hid device stream is being closed, it could invoke >>> another VT callback function to let the VT subsystem know that any >>> bindings for that device stream should be torn down. >>> >>> all this io-redirection complexity is being introduced by the fact that >>> we want to support VTs. hence, at least to me, it makes sense to have >>> the VT subsystem track and manage this complexity. handling this all >>> automatically in the VT subsystems seems like a much cleaner approach >>> than forcing every VT consumer (like the X server) to manage system VT >>> device io. >>> >>> ed >> -- >> 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. ????????????????????????
