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. do you have any specific examples of these types of applications and how they work? > 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? 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? > 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). 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. > ????????????????????????
