lkml.org 
[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: uniform input device packets?
On Thu, Jun 25, 1998 at 09:40:04 AM +0200, Vojtech Pavlik wrote:
> On Thu, Jun 25, 1998 at 03:16:51AM -0400, James Michael Mastros wrote:
> > (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.
I supose you could do that -- though that would be implying instantaneous
key-pressing (time of down==time of up).

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

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans