> > Then we'll generate both 'pressed' and 'released' events when we receive
> > it. This is for example valid for the 'Pause' key on a PC keyboard.
> I supose you could do that -- though that would be implying instantaneous
> key-pressing (time of down==time of up).
Actually the Pause key does exactly this - it (in hardware)
sends a press and an immediate release. We could add a
generated delay between those, should this be a problem,
which I doubt.
> > Lights on keyboard are not input.
> So we are going to have a protocol with _no_ bi-directionality? That dosn't
> make much sense, IMHO -- even (old-school) printers can report out-of-paper,
> offline, etc. Keep simple bi-directionality. It shouldn't break the
> protocol -- if it does, then it was an _awfuly_ brittle protocol.
Well, I wanted to use the other direction for inserting
synthetic events into the queue, so that one app could
generate them and a different one read them.
On the other hand, both might work at once (and we could use
this for force-feedback, too). I think we should use separate event
types for leds, and motors and such, too, because these
simply are not keys, eventhough they're booleans and or
integers.
> > There are five ways out of this:
> >
> > 1* say that 256 is enough for now ;)
> > 2* split a chinese keyboard into two or more devices
> > 3* extending the number field to 16 bits
> > 4* swapping the fields around for buttons
> > 5* adding more types to the type field, eg. 0,1,2,3 - button set 0-3,
> > 4 - axis, 5 - rel. axis
> >
> > Which would you go for? Myself I would choose either 3* or 2*.
> 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.)
If you used 3*, you'd use one byte more, but would have
65535 axes as well, and won't have trouble reporting status
of a nuclear plant control panel ;)
Myself I think it is better to use more bytes than to use
more complex routines.
> > I think that it'd be nice if the application kept working if I run in on a
> > PC or on a Sun, with completely different keyboards. How to do it, is the
> > question.
> > 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.
> > 3* same as 2* except that the ioctl would return namestring of the
> > key/axis
> Even worse -- \` can be a "backquote", an "acute accent" a "negitive-slope
> accent", or several other things in several languages that I can't even
> pronounce. Also, userspace might not care about what the fourth key on the
> top row is unshifted, but shifted -- a dollar or a pound?
The names would have to be registered in some central
registry to be at least a bit standard, anyway.
> > 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.
With your approach every application that uses the device
directly needs to be configured by the user separately. This
can be pretty annoying.
Vojtech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu