Hi Ed, I think I'd better make my justifications of not binding hid devices to VTs clear so that they won't not buried under the details.
These devices are shared devices, not for exclusive usage of Xorg or VT, Although Xorg and console might be the biggest consumers. The actually users/applications should get to decide which stream should get the input. We kernel should never make the decision and assumptions on behave of them. If they are exclusively used by console and Xorg, I will be more than happy to bind them to VTs. I just thought another small scenario which may explain my concerns a little bit. There are 2 keyboards -- K1 (/dev/usb/hid0) and K2 (/dev/usb/hid1) on the system. On /dev/vt/6 which is a text console session, the root user wrote an application to listen to /dev/usb/hid0 with the purpose of debugging or whatever. Xorg starts on /dev/vt/7, and it is configured to use keyboard1 and keyboard2. So it registers K1 and K2 to the kernel so that both of them are bind to VT7. The user switches Xorg to VT6, during the switching, since K1 and K2 are bond to VT7, and VT6 is console session, the streams of K1 and K2 are switched to the internal one. The user process which is listening to /dev/usb/hid0 will starve on /dev/vt/6 though K1 has inputs. With HIDIOCKM[GS]DIRECT ioctls the user application at least have an option to switch the stream back by either set up a timer as I described before or using NONBLOCK read. If I was wrong, please correct me. Regards, Aaron Aaron Zang wrote: > > > 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. >>> ???????????????????????? >
