[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

     \ /
      Last update: 2005-03-22 13:43    [W:0.042 / U:1.836 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site