Re: mousedev patch

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

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

The /dev/ts stuff. I didn't expect it to be so broken.

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

> Ahh -- I misread you. 'Twould work rather well for evdev, though,
> don't ya think?
> 
> Or do you have any alternate proposals?

Either way we end up with a mess.

Method one is like the IRIX stuff:

   All input events are read from a input queue.
   Their is a special /dev/qctrlN so you can control each device.
   
Method two.
   We use one file to see if a new device is added/remove.
   Input events are read from individual devices. 

So it is really the flip side of a coin. Both methods get hairy.

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

Since this is such a issue and I also have written code to deal with this
hot plug issue I will write a library to hides all the "nasty" from the
apps.