> > Do you know of such hardware? (That would send the same data when a key is
> > pressed and when it is released? That's very broken. IMNSHO)
> No, I don't, and agreed. Just thinking of devices that would screw us over.
> (And now that I think of it, there _are_, doubtlessly, things that don't
> give a "down" event and then an "up" event, but mearly a "pressed" event.)
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.
> > For this
> > hardware it'd be best to assume that at powerup no keys were pressed and keep
> > track on what is pressed and what not in the driver. No need for a 'toggle'
> > event.
> But that way we need to keep track. Let userspace make the asumtions. (I
> still think that we need it just for blinkenlights. Ease-of-use for
> userspace to be able to say toggle instead of query, compute, set.)
Lights on keyboard are not input.
Also, we should make the interface as simple as we can, hiding all the
hardware stupidness in the kernel. So it is better to keep a track of what
is pressed (that is a bitmap of <= 32 bytes), than have to add another
event type.
> > If you use 8 bits per button number you can't easily predefine all standard
> > keycodes, since there is definitely more than 256 different keys in the world
> > (though not on the same keyboard).
> Gotcha. (And a Chinese keyboard could have over 256 keys. Which is why
> they don't make Chinese keyboards.)
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*.
> > Myself I would stick with the simplest protocol (8 bits event type, 8 bits
> > axis/button number, 16 bits data), because it's 32 bits in total, which makes
> > things nicely aligned, easy to decode, and stuff.
> But we've spent 5 or 6 mails talking about why that protocol wouldn't work
> -- not enough buttons/axes.
With 8 bits per axis/button number you get 256 buttons + 256 axes + 256 rel. axes.
With the other scheme you'd get 65536 buttons + 26 axes + 26 rel axes.
I think that both offer quite enough of axes and buttons.
> Hmmm... I'd say that what we want to do is give an arbitrary 1:1 mapping of
> phisical keys and keycodes, and a way for userspace to get all info that
> kernelspace knows about the keyboard (which AFAIK isn't much). That is to
> say, we make no guarantee that key 1 == Q, but that on all keyboards that
> pass us the same data, key 1 is the same key. If we get keycode 126 from
> the keyboard, we don't stop to think about what type of keyboard it is and
> what 126 means, we just put out the event "bool 126 = true". Let userspace
> figure out that they are using a Win95 keyboard and hit left-win.
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 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
3* same as 2* except that the ioctl would return namestring of the key/axis
4* same as 2* without providing anything, and requiring user configuration (keymap)
Which would you choose here? I prefer 3* or 2* ....
Vojtech.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu