Re: event mixer patch

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

> But do we need to support EV_ABS devices at all on mixer devices? I would 
> rather restrict us to applications that make sense, at least I can't think 
> of a legitimate reason to mix them.

Yes if the only device is a touchscreen which usually have absolute value.
You could then get software like gpm or X running in no time using the
PS/2 mouse interface. 
 
> Hmm, if we had a single /dev/eventstatus device receiving 
> CONNECT/DISCONNECT messages (or should we send them per eventX device as 
> EV_STATUS messages?) we would be independent of the hotplug system, dunno 
> if that has advantages/disadvantages...

Disconnect is easy to handle. You get -ENODEV when you attempt a read. It
is the connect that is harder to deal with.
 
> Anyway, thinking about the 3 major scenarios for the input system usually 
> helps me:
> 
> 1. 1 user, 1/2 head, multi inputs: currently the major linux use I guess, 
> so anything we do should give these users a nice plug-and-play feeling. Eg. 
> plugging in a keyboard should make it immediately useable (currently not 
> possible with _event_ devices, unless the application scans them all)

Kernel wise i.e the console system it auto detects. As for userland I have
encountered this problem. I still haven't found a solution except to have
the user run a app to make everything aware a new device has been plugged
in. This is done by scanning the /dev/input directory. This is not a good
solution IMHO. If you a embedded device and lack the software to start the
hardware or lack the ability to login into the serial console to setup the
device then you are in trouble. 

> 2. multi user, multi head, multi input: here we have to make sure that we 
> don't loose the user/input assignement, eg. unplugging/replugging an USB 
> joystick should let me continue to play the game :-)

Ah. The topology problem. The solution here is to make a particular device
belong to a particular group. If I plug in a joystick I don't so other
person at some other desk being to able to see what my values are. They
could cheat at the game then. The trick is then getting that joystick once
plugged back in to the correct desktop. This is very trick. I still
haven't figured it out yet.

> 3. embedded/industrial use: here we have all possible kinds of sensors and 
> actuators handled by specialized applications and so we just have to give 
> the applications all the necessary information to allow them to react 
> properly. Eg. should a bus failure result in a EV_DETACH(reason bus 
> failure) message?

Hum??

> The simple eventmix patch only helps for point 1 above, that's why I think 
> it should be extended to be useful for point 2/3 too..

P.S
   I like to down the road work on a input filesystem which I hope will
also address these problems. I remember in one discussion with Viro about
needing a xxdevctrl file for each device file system. I question Viro if
we really needed it. When it comes to hotplug and power management perhaps
he was right.