Re: mousedev patch

[James S. <jsi...@tr...>]

> > 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.