Re: New to the input layer

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

At 23:36 03.07.00, Vojtech Pavlik wrote:
> > > > - 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.

Seems like a quite difficult task to me...


>The device number is currently held busy until it's not referenced
>anymore. It doesn't have to be so.

Hmm. Let me think about that... What will the application see? I don't see 
a type  like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?

> > > > - only 32 event devices, looks a bit short sighted?
> > >
> > >There's space for up to 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 see. Actually, what I'm looking for is a reasonable simple way to port 
some legacy (but unfortunately still needed) applications to the input 
layer... Hmm, I can live with mice and keyboards being separate, so would 
you accept if I added a keyboard mixer device to keybdev.c?


> > > > - the [sg]etkeycode ioctls are not implemented yet, anyone working on
> > > this?
> > > > If not, I'll probably give it a shot
> > >
> > >Please do.
> >
> > OK, I will try to come up with a patch this week.
>
>The ioctls should modify the event->keymap structure.

Sure. But you mean event->keycode, or?


> > >Really? What keyboard is it and what keys it doesn't report to have? I
> > >think this is more likely to be included in a 'blacklist' in the hid
> > >driver.
> >
> > It's a Lindy USB kbd for Macintosh, german version. It looks similar to 
> the
> > MacSense one. It reports itself as ALCOR 9410 (this seems to be the ID of
> > the generic Alcor kbd/hub chip, so it's probably hard to distinguish from
> > PC keyboards), language ID 409. The missing keys are KEY_POWER (0x66) and
> > KEY_KPEQUAL (0x67). I'll try to find out if MacOS uses some initialization
> > USB command to switch the keyboard to a different mode.
>
>Ok. Implementing setkeycode with USB keyboards won't be easy, since
>hid.c has a quite complicated structure for this. If you won't be able
>to find any such initialization (and even if you will) I think an
>exception in the hid.c driver for this keyboard will be needed.

I'll try to find out more.

BTW, are there any known problems with the current backport and console 
switching? It seems to lock down some of the modifier keys from time to 
time, then you have to press all of them to get them back in a known state.
And it seems the LED status sent to USB keyboards is inverted.

Franz.