> > 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.
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.
> Also, we should make the interface as simple as we can, hiding all the
> hardware stupidness in the kernel.
I supose -- If they realy want to see all that stupidity, let them ioperm()
themselves up the wazzo.
> > > 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*.
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.)
> 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.
I thought that we were talking about not joining the number+value for
buttons here. If you do, then it is enough, I think.
> 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
But we don't know the label on the keyboard unless sombody tells us -- you
can't tell an azerty from a qwerty programaticly.
> 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?
> 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.
-=- James Mastros
-- True mastery is knowing enough to bullshit the rest. -=- Me- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu