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 Wed, Jun 24, 1998 at 11:28:33PM -0400, James Michael Mastros wrote:

> > Yes. Myself I think we could leave out the devicetype field at all.

> I don't think so... that way you couldn't search for a certian device, or
> find out what the type of a device is given an arbitrary node. However, I
> don't think we need to stamp every delta with it. Keep it out of band, in
> an IOCTL where we don't have to worry about space. (Along with other info
> about the device -- semi-standard keys on a keyboard, odd buttons on a
> mouse (rollers, rocker-switches, etc)...)

That's what I was thiking about. Something like a "INPUTIOCGTYPE" :)

> > Actually, as far as I know there are only 5 types of events:
> >
> > * button (key) press
> > * button (key) release
> > * button (key) autorepeat (might not be necessary)
> > * absolute axis (integer) change
> > * relative axis (integer) change

> I'd kill the autorepeat, and stick in an "other" -- think of the
> hypothetical motion dector. (Like ANSI C and the toster.) Acatually, I
> think what we want to say is bool/delta/absolute integer. (2 bits, with a
> spare. <G>. Give it a whole byte.)

Okay. :)

> > Timestamping isn't silly, as I explain in another reply to you.
> > It's actually very much needed.
> Indeed. However, I think a simple jiffy-count will do nicely.

However, jiffy count isn't directly real time related, because not
all machines use the same timer interrupt speed. (PCs - 100 Hz,
Alphas - 1024 Hz). It'd be better to define it's either in miliseconds,
or microseconds. However, on machines without better timers, the
number could be purely based on jiffy count, only multiplied with a
constant.

> > 12 bits is too small as well, imagine a high resolution tablet. It won't
> > do. 16 bits is much better, maybe 32 would be best.

> I think your both forgetting that we need to give the axis number and the
> position.

No. There are two ways how to define button events. First, simple, and
not very effective, currently used in the joystick driver:

1 byte - event_type
1 byte - axis/button number
2 bytes - new_state

Event_type is here 1 for buttons and 2 for axes, number is clear I think,
and new_state will be 0, 1, or 2 for buttons/keys, and integer for
axes. This is not too good, since we are limited to 256 buttons. The limit of
256 axes isn't a big problem. To circumvent this problem, we define that

* for axis events everything will stay as is
* for buttons we define three new event types press, release, and repeat
* for buttons we put the number into new_state field instead of number field

With this we easily gain 65536 buttons. The original proposal did go even farther
by merging the event_type and number fields into one, saying that it will be:

* '0' - Button press
* '1' - Button release
* '2' - Button repeat
* 'a' - 'z' - Absolute axis 0-26 change
* 'A' - 'Z' - Relative axis 0-26 delta

With this we limit number of axes to 52 in total, however get 65536 buttons.
Whether we need this is a question, of course. Should we use some standardized
codes for keys; then yes.

> Make it a varable number of even bytes. I'm thinking that each read would
> return one event, so the end of the read can signify the end of the event.
> Otherwise, give a count of bytes then the data.

I think the event size should ALWAYS be the constant. And I think that on
each read we can return as many events as we want, but it should be a whole
number of events.

Vojtech

-
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    [W:0.088 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site