Re: mousedev patch

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

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

Basically what we are doing is looking where to place the middleware. To
handle the one device file to many hardware devices we have to implement
some sort of filtering kernel side. The other side of the argument is we
push the filtering to userland. 

Charles is looking from the userland perspective to ensure backwards
compatiablity and making it easy to program. 

Vojtech and I are looking form the kernel side which involves adding
things like filters.



   After much discussion at work with my co worker we came up with the
pros and the cons of having it userland or kernel side. We looked at what
already exist. For linux we pretty much already have a system setup kernel
side. Its the network layer. We can do various types of network filtering. 
From the network layer we can see the issues that would come up. One is 
backwards compatiablity. If you upgrade your kernel you might have to
upgrade your software. Often we are left keeping the old code around just
to be backwards compatiable. Example is the ip toolchains. As you can see
in as time goes on the rules get more complex and more code gets added to
the kernel. 
    The other thing is userland has far better and faster evolving
tools when it comes to filtering than the kernel could ever have. Plus we
just can never know what kind of crazy filters people might want. What I
want to use my 3rd mouse only when the moon is full. This is something you
can't do easily kernel side. 
    The third thing about doing it userland side is if we implement a
library to hide such "nasties" is if the library API is go enough it can
be made to work on other platforms like BSD or solaris. This is the most
powerful thing since we can hide the very different types of behaviours
each system can exhibit and make them appear to work the same on each
system. Programs can be made to work on different platforms very easily. 

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

No doubt they have to reworked to use such a library but the benifeits
outway the cost. If the api is simple and exist on many platforms you will
see people migrate really fast.