Re: mousedev patch

[Vojtech P. <vo...@su...>]

On Fri, Aug 03, 2001 at 10:37:53AM -0700, James Simmons wrote:

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

I prefer method two. The point is that, though not being completely
straightforward, every bit is kept simple and easy to understand.

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

Well, for one mouse you only need to select/read/whatever only one
file/device at a time. The file may change, though.

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

I'm not sure if you can do that for apps that pass the fd from the
driver to the core to a central select() call which waits for events. If
they're braindamaged enough, they can't be helped.

-- 
Vojtech Pavlik
SuSE Labs