Re: mousedev patch

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

On Thu, Aug 02, 2001 at 10:07:16AM -0700, James Simmons wrote:
> > I'd rather not do this yet -- some applications don't support /dev/ts
> > properly, and it's extremely useful to be able to use either driver
> > with either kind of input device (in the case where one has a system
> > with both a mouse and a touchscreen attached).
>=20
> Which apps? Only X to my knowledge and a few other unknow apps use it.=20
> In the end apps should be ported over to use the event interface.=20

Are you asking which apps use mousedev? GtkFB, QtE, Nano-X
(Microwindows) and gpm, to name a few off the top of my head. Or are
you asking what uses Compaq's /dev/ts? X, Microwindows and QtE (though
it looks like it was patched in at the last minute there;
additionally, X's /dev/ts support is rather broken, having no support
for moving the cursor without the button depressed, though we should
be fixing that here soon).

I absolutely agree that apps should be ported to use the event
interface -- that's why I'm arguing for an event interface which is
easy to port to (ie. doesn't require any framework changes, which
listening on multiple fds does impose).

> > This will be less acute when a single interface is available which
> > provides applications with all available information (such as James's
> > suggestion of an evdev mixer which adds a field giving the minor
> > number of the evdev device correspending with the source).
>=20
> This is for /dev/shmiq support on IRIX platforms. BTW it is not a easy
> device to work with.

Ahh -- I misread you. 'Twould work rather well for evdev, though,
don't ya think?

Or do you have any alternate proposals?


Note that I won't be able to spend the time to write such an evdev
mixer and port the apps we support here (pretty much those listed
above, and X) to it at least until next month. When the time is
available, however, I'd be glad to do so; in the interm, we can come
to a design that everyone can agree to.

My basic requirement (which I'm loathe to negotiate on) is this:

- Hotplug and ready event notification must be available from one fd.
- It must not be necessary to perform any blocking calls (or a
  select() except with a zero timeout) on more than a single fd, this
  single fd presumably being that mentioned above.

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.