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
