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
