Thanks for accepting the differences. Regards, Aaron
On 06/09/09 03:47, Edward Pilatowicz wrote: > On Sat, Jun 06, 2009 at 09:32:41AM +0800, Aaron Zang wrote: >> 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. >> > > so imho, your optimizing / designing these interfaces for a very > uncommon use case. you're a kernel developer, so accessing hid0 devices > for debugging is a common use case for you, but do you really think that > accessing hid devices directly is a common use case for most (any?) > solaris users? > >> 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. > > so this scenario is already fundamentally broken. we have two entities > listening to the same hid0 device, which you told me earlier will result > in non-deterministic behavior. so now your trying to support a scenario > where X (or the app) can't work correctly. > >> 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. >> > > this is the same thing that would happen if the X server issued your > propsed ioctls. > >> 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. >> > > sure. if the (fundamentally broken) application is aware that streams > output can randomly stop, it could use these ioctls to switch data back. > now the (fundamentally broken) app can become even more complex, with > timeouts and async IO all to manage the fact that input might randomly > stop. > > for your scenario above, it seems that what you really want it a way for > an application to get dedicated access to a hid devices. if your app > (debugging or whatever) could request dedicated access, then it could be > written correctly, since it would never share the device with the X > server, and additionally the hid data could never be randomly > re-directed somewhere else while the device is in use. > >> If I was wrong, please correct me. >> > > i don't think either of us is wrong, we just have a fundamental > difference of opinion. :) > > i think these interfaces push unnecessary complexity into the X server. > that said, i think we've beaten this dead horse enough. you've already > got your +1 and you've got sign off from the X folks for adding these > interfaces. hence, we should just agree to disagree on this issue. > > ed -- You know some birds are not meant to be caged, their feathers are just too bright. ????????????????????????
