Re: event mixer patch

[Franz S. <Fra...@la...>]

At 00:48 20.06.2001, James Simmons wrote:

> > > Is this a seperate patch or the patch from Charles? I looked at his patch
> > > and it has only one line change in input.c. Very nice patch. After I'm
> > > done with power management today I will incorporate it. Probable some
> > > time tomorrow unless Vojtech has any objections.
> >
> > Last time I asked Vojtech wasn't very pleased of that idea, eg. it doesn't
> > make  much sense to mix in EV_ABS devices.
>
>Your right. I have this problem with a userland program I wrote. The way
>I got around that was to emulate each absolute device as a relative
>device.

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.


> > Maybe it should be a separate module providing a whole class of event mix
> > devices, with all EV_KEY and EV_REL mixed on /dev/eventmix0 by default. 
> Then
> > there could be ioctl's to attach and detach single event devices onto the
> > mixer devices.
>
>The real underlying problem is knowing when a device gets attached and
>detached. How do we know that? It is not easy to solve. A mixer sort of
>gets around this problem. Then we run into the problem of EV_ABS type
>devices. The mixer device could be used to tell us when a new device is
>added or subtracted. Then we can decided to add the new device to the
>mixer.

Well, I thought the hotplug stuff works for USB? I have never used it 
though, cause I have currently no need for it.
Excuse me if I'm wrong here, but I thought the procedure would look like 
this for example:

  - USB mouse is plugged in and attached to eventX
  - hotplug scripts get called
  - scripts determine if THIS mouse is assigned to a mixer device
  - scripts issues ioctl("attach eventX to eventmixY") if assigned (maybe a 
packet controlled /dev/eventmixcontrol makes more sense than an ioctl)

The application using eventmixY won't even notice anything, except for the 
additional packets.

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

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)

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

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?

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

Franz.