> > > 1 byte: describes the type of event happening:
>
[...]
> 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.)
> > > 8 bytes: a base64 (32 through 95) timestamp containing a 32-bit value
> > > (unix time) and a 16-bit value (number of 65536ths of seconds)
>
> 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.
> > > 3 bytes: the argument to the event:
> >
> > Since even the standard PC keyboard has 102 keys (and some have a few
> > more), I'd venture to say that no one device will have more than
> > 255 (2^8) "keys" or identifiable inputs. For items with absolute
> > positionings, I think -127..128 is a bit small of a range. Since the
> > we only used 4 bits for the event-type, lets make this 12 bits large,
> > which will give us a range of -4095..4096, which should be plenty.
>
> 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.
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.
-=- 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