> > I'd go for 4. We want to provide _lots_ of room to grow. Remember when
> > 640k was enough for anybody? I think here 64k will do, but 256 is a bit
> > short. (Yes, the current keyboard driver gets away with 128.)
Whops. Memory-numbers-bad. I meant 3*.
> > > There are four ways for this:
> > >
> > > 1* assign each key (depending on its label on the keyboard) a unique
> > > 16-bit number
> > > 2* number keys from 0 sequentially and provide some ioctl for querying the
> > > above ID
> > But we don't know the label on the keyboard unless sombody tells us -- you
> > can't tell an azerty from a qwerty programaticly.
>
> Yes, but the somebody can tell the driver - he has to do it
> for joysticks and mice already, so I guess this isn't a big
> problem for the keyboard.
Why does he have to tell _the driver_ for joysticks and mice? When we get
an event for the third axis, we report it -- we don't care how many axes it
has. If the app wants to know, it can look in /etc/whatever.
> > > 4* same as 2* without providing anything, and requiring user configuration
> > > (keymap)
> > What I'd go for. We would tell them everything that we can tell about the
> > device -- which isn't that much. For all we know, some joker pluged in a
> > Klingon keyboard into our PS2 port and didn't tell us. Let userspace sort
> > it all out.
>
> We could require the joker to tell us. Actually it wouldn't
> be bad if every application would know just by querying the
> kernel and not the user, which keys the attached keyboard
> has and if it can use some key that is not available on
> every keyboard, but would be very useful for the app for
> example.
Or the application could look in /etc/keyboard. That's better done in
userspace rather then userspace telling us so we can regurgate the info back
later. (That being, after all, what block devices were made for. <G>) We
should be able to tell userspace all we know, and not rely on it to tell us
stuff.
> With your approach every application that uses the device
> directly needs to be configured by the user separately. This
> can be pretty annoying.
Along with the monitor... there are simply better ways of globaly
configuring both then sticking the data into kernelspace and then getting it
out again later. The data should only come from kernelspace if it comes
from the hardware. That's what they call it userspace for.
-=- James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu