[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: uniform input device packets?
On 1998.06.25, Vojtech Pavlik <> wrote:
> > > 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 ;)

256 is more than adequate, now or ever. My guess.

> 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

*shrug* Maybe.

> 5* adding more types to the type field, eg. 0,1,2,3 - button set 0-3, 4
> - axis, 5 - rel. axis

Don't want to bother understanding this.

> Which would you go for? Myself I would choose either 3* or 2*.

For odd devices, send 2 events down the pipe for every 1 distinct
event. This way, you don't penalize "cheap" devices that don't
need to send a lot of data, while "complex" devices can generate
all the information they want. For your chinese-keyboard example,
a regular keyboard won't have more than 255 unique events. Great.
For a hypothetical chinese-keyboard enabled with, say, 1024 keys
(or more), you'd send the first event tagged "meta-data"
identifying it as meta-data with some bits, and some meta-data
describing the "group" the next event will be part of. So, you'd
say "the next event is group 0" which maps to keys 0-255, or
"the next event is group 1" which maps to keys 256-512, etc.
Yes, this will mean that "complex" devices will generate twice
as much data, but not every device (hopefully, "few" devices)
are "complex" in this fashion.

This allows the majority of devices to remain lightweight.

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

Keys should pass down their generated scancode, and map scancode to
key-equivalent from userspace. This would require something in
userspace understanding given the type of keyboard attached what
key maps to what scancode.


Now I'm who I want to be, where I want to be, doing what I've always said I
would and yet I feel I haven't won at all... (Aug 9, 95: Goodbye, JG.)
"You should change your .sig; not that the world revolves around me." -s. sadie

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.038 / U:26.860 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site