Re: New to the input layer

[Vojtech P. <vo...@su...>]

On Mon, Jul 03, 2000 at 06:57:31PM +0200, Franz Sirl wrote:
> At 17:57 03.07.00, Vojtech Pavlik wrote:
> >On Mon, Jul 03, 2000 at 01:02:08PM +0200, Franz Sirl wrote:
> > > Hi,
> > >
> > > I'm currently working on the integration of PMac ADB into the input layer.
> > > I use the 2.2.16 USB backport for my work and most stuff works well
> > > already. But I have some generic implementation questions now:
> > >
> > > - who will assign a BUS_ADB number? I used 0x17 for now
> >
> >That's ok.
> 
> Fine. Please update input.h then, I'll remove my local definition as soon 
> as they collide :-)

Ok. Added.

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

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

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

> >None - the Fn key on notebooks usually doesn't generate any scancodes.
> >Anyway, the "KEY_MACRO" (112) would make sense - it's used for keys like
> >that (Macro key, Logitech key, Multi key, or the Fn key).
> 
> Aha, thanks. Some Powerbooks with ADB keyboards seem to report this key.

Ok.

-- 
Vojtech Pavlik
SuSE Labs