lkml.org 
[lkml]   [1998]   [Jun]   [24]   [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 10:13:53 PM +0200, Vojtech Pavlik wrote:
> On Wed, Jun 24, 1998 at 02:23:35AM -0400, Allanah Myles wrote:
> > If we're safe to assume that 8 (2^3) devices of any one type is
> > sufficient, and that there will never be more than 32 (2^5) different
> > types of devices, then we can represent this information in 1 byte. We're
> > basically saying that each device/ID# is unique, allowing for a *total*
> > of 255 (2^8) possible devices (although no more than 8 in any category).
> > I think this is sufficient.
>
> 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)...)

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

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans