Re: New to the input layer

[Matan Ziv-Av <ma...@sv...>]

> > > > - why is there no mixer device /dev/input/events similar to
> > > > /dev/input/mice? Should I implement such a device?
> > >
> > >Is it needed for anything?
> >
> > Well, I have noticed that on unplugging/replugging a device, it won't
> > re-use the previous /dev/input/eventX if it is still held open by an
> > application. That means applications have to scan the event devices
> > continously themselves as soon as the device is removed, to check where it
> > reappears. Think about an X user which unplugs his keyboard, plugs in a
> > mouse and replugs the keyboard, does X have to scan then on which eventX
> > device the keyboard reappears? I think this is overkill for the usual
> > single-user single/multi-screen installations which probably make up 99.9%
> > of all installations. With a /dev/input/events mixer device X can attach to
> > a single device for all events and doesn't have to care what the user does
> > with them. Maybe a ioctl to attach/detach event devices from the event
> > mixer would be a good idea then.
> 
> Creating /dev/input/events is the wrong approach. Creating a way how to
> make an already-open disappearing and appearing again device to appear
> back at the same device number.
> 
> The device number is currently held busy until it's not referenced
> anymore. It doesn't have to be so.
> 
> > > > - only 32 event devices, looks a bit short sighted?
> > >
> > >There's space for upto 196 (64-255).
> >
> > Yes, I know. I was searching for a good minor for /dev/input/events.
> > Probably 255 then :-).
> 
> I really don't think it's needed. We would have to add some device ID to
> struct input_event, because mixing input from a joystick and a tablet
> (or two joysticks or whatever) simply wouldn't work.

I think that can be useful. There are many more scenarios of device
numbers changing:
* My usb hub causes a complete rescan when a device is inserted/removed.
* If some of the input device drivers are modules that are periodically
  inserted/removed by kmod. 

If you make the ID unique (use 32 bits, and no reuse should be good
enough), and add in the device info also serial number and some kind of
geometry (where applicable). Then it would be easy to change the X
server (and other application) to take the following instructions:
use only the btc keyboard or
use only the keyboard with a given serial number or
use only the keyboard connected to the ps/2 auxiliary port or
use only the keyboard connected directly to the usb host

The former two are useful to make sure X uses the same keyboard, no
matter how/where we connect it. The latter are useful for making X use
the keyboard which is in the same location, no matter which it is.

I don't see how can this be achieved in the current scheme, since the
application cannot know when a new device is connected, and can't use
select/poll on non existing devices.



-- 
Matan Ziv-Av.                         ma...@sv...