Re: mousedev patch

[Charles D. <cd...@mv...>]

On Thu, Aug 02, 2001 at 08:30:42PM +0200, Vojtech Pavlik wrote:
> On Thu, Aug 02, 2001 at 11:13:21AM -0700, Charles Duffy wrote:
> > Being able to wake the mouse driver from more than one source (ie.
> > separately for /proc/input/devices and /dev/input/eventX) will require
> > a level of app restructuring in more than one case which I believe is
> > unnecessary and will reduce driver availability without good cause.
>=20
> Would there be a problem with
>=20
> 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 /proc/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).
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).

I'm looking over the apps which will require modification. Qt/E
(thanks to its signal/slot notification) will be fairly
straightforward to support with the plan you propose; XFree86 also
looks straightforward (as much as it ever is). Microwindows, on the
other hand, will not be possible without architectural changes as it
requires a non-blocking mouse driver and provides no means of changing
the single fd which is select()ed on after open. Looping inside the
driver between 1 and 1a is as bad as a blocking select -- the point is
that the mouse driver's functions should be active very little time,
and only called when the single fd which it select()s on is ready.

> We can't sanely mix all event sources into one, because there are
> 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.