Re: New to the input layer

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

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

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

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


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

> > - it seems an ioctl to set the key bitmap is needed, cause I have an USB
> > keyboard here which reports 0x65 keys, when in reality it has 0x67 :-(
>
>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.


> > - what key entry in input.h relates to the "Fn" key found on notebooks?
>
>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.

Franz.