Re: mousedev patch

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

On Mon, Jul 30, 2001 at 10:19:47PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 30, 2001 at 11:33:24AM -0700, Charles Duffy wrote:
> > There's quite a bit of software written (Qt/E, for one; Microwindows,
> > for another) which already has a mouse-handling architecture which
> > allows the mouse driver to open() a file, which is then returned by
> > the driver; the framework select()s on that file (among other things),
> > and calls the mouse event handler when select returns with the
> > appropriate fd.
>=20
> Unfortunately this probably won't help us with hotplugging.

If the only change is to add an extra field with the minor number,
then it won't. If, however, a means of notifying processes of
added/removed devices (ie. creation of a EV_CON w/ connection and
disconnection events, the latter only sent through the mixer), it will
do plenty of good.

> > Writing evdev drivers for this software would mean not only writing a
> > new driver module (a trivial task) but rearchitecting the framework to
> > allow drivers to own (and pass to the core) multiple fds, and
> > attempting to get these patches accepted by each of the projects in
> > question.
>=20
> Only if you want to use more than one mouse at a time.

=2E..or you want to have one device which, when opened, will *always*
get your mouse (whichever kind it may be). This is not an uncommon
case -- and being able to switch mice without restarting X (or
whatever the app may be) is most certainly useful.

> > Furthermore, there's no means of detecting disconnection/reconnection
> > -- another thing that an extended evdev mixer could (and, IMHO,
> > /should/) report.
>=20
> Disconnection is signalled by evdev by returning -ENODEV on read(). The
> process will be woken up on disconnect.

Quite right. But in Microwindows (for instance), disconnection of the
mouse will cause the system to die, without even calling the mouse
driver for its advice. One of the assumptions the system is based
around -- an assumption which is valid everywhere else -- is that mice
will *not* be hot-plugged, or that if they are the device will still
remain valid in the mean-time.

I'm not familiar with the behaviour of Qt/E or X in these cases, but
I'd be unsuprised were they similar.

> > Assuming that all evdev devices support USB is
> > faulty -- I personally have some that aren't (including some
> > non-hot-pluggable devices which may be rmmod'd on entry to powersaving
> > mode and re-insmod'd on restart; it's quite unuseful if applications
> > can't detect new minor numbers and such as a result of such things).
>=20
> How would you propose detecting new minor numbers? I'd suggest doing it
> the same way as USB does with new devices - read /proc/input/devices for
> an uptodate list, select() on the very same file to get notified of its
> changes.

If the evdev mixer is implemented inside the evdev module, it will
have access to the evdev_list, and thus the evdev struct including the
minor number.

As for /proc/input/devices, while the concept is great in theory, it
would vastly complicate the task of writing evdev-based drivers for
application software.

It will mean that the existing mouse interfaces (which
near-universally assume that an input driver, when it initializes,
will only need to be notified of events from one fd; that this fd will
never change; that when the file is closed on the other side, there's
no recovery possible) are insufficient, and that the userland
frameworks providing them will need to be rewritten (perhaps meaning a
rewrite for the other mouse drivers included in these packages as
well).

In short, making it necessary for a mouse driver to monitor more than
one file means /a whole lot more work/ for those of us writing evdev
drivers on the userspace end -- and that's not good for anyone.