Messages in this thread |  | | | Date | Thu, 25 Jun 1998 04:20:40 -0400 | | From | James Michael Mastros <> | | Subject | Re: 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
|  |