Re: mousedev patch

[Vojtech P. <vo...@su...>]

On Fri, Aug 03, 2001 at 11:04:35AM -0700, James Simmons wrote:
> 
> > > Would there be a problem with
> > > 
> > > 1) Opening and parsing /proc/input/devices.
> > > 1a) If no device is found either go to 1) if non-blocking is required
> > >     or select() on /proc/input/devices and then go to 1)
> > > 2) Opening the correct /dev/input/eventX
> > > 3) Read the event data
> > > 4) If -ENODEV received go to 1)
> > 
> > There are a few problems here:
> > 
> > 1. It isn't possible to read from two devices simultaneously while
> >    still conforming to the single-source requirement. This is
> >    extremely useful when, for instance, a device has both a touchpanel
> >    and USB ports (ie. the Hitachi webpad).
> 
> WHat do you mean by single source requirement?
> 
> > 2. Some mechanism will be required to allow the app to modify the fd
> >    in the select list used by the framework (in switching between
> >    steps 1 and 2 or 4).
> 
> Example? 
> 
> > > devices which generate lots of events and it'd be not a good idea in
> > > my opinion to feed all of them to the app.
> > 
> > So the app can use ioctl()s to decide what it does and doesn't wish to
> > hear. Perhaps the mixer initially provides nothing but attach and
> > detach events until the app adds additional sources via ioctl()s.
> 
> This is the mess a was talking about with the IRIX implementation. The
> more devices you have the more chance of losing event packets since you
> get a flood of them then. Plus what if one device goes crazy. Then 90%
> of the event packets coming in block the other devices. We actually had
> this problem with one device here at work. What had to do certain tricks
> to make sure everything got a fair share. The IRIX implement uses the
> qnctrl device files to manage this. 

I really would like to avoid this route if possible.

-- 
Vojtech Pavlik
SuSE Labs