Re: uniform input device packets?

Allanah Myles (dossy@panoptic.com)
Wed, 24 Jun 1998 02:23:35 -0400


On 1998.06.23, Mathieu Bouchard <boum01@UQAH.UQuebec.CA> wrote:
> okay... this is my first attempt at slightly bloated protocol design.

Don't they always start like that? =)

> A packet could be:
>
> 1 byte: a signature 'i'.

(Unnecessary, already discussed elsewhere.)

> 1 byte: the device emitting the signal:
> 'k'==keyboard, 'm'==mouse/trkbl, 'l'==lightpen/pad,
> 't'==thermometer, 'j'==joystick, ...
> this byte should be rethought better, maybe.
>
> 1 byte: an ID matching /^[0-9A-Za-z]$/ case-sensitive numbering the
> device. only when talking about several devices on the
> same channel.

Why a whole two bytes? Do you really believe someone will have more
than 9 devices of the same type in any given system? (Yes, this will
be a design decision that's based solely on speculation...)

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.

> 1 byte: describes the type of event happening:
> '0'== a boolean has been reset.
> '1'== a boolean has been set.
> '2'== a set boolean is auto-repeating.
> '@'== the absolute integer #0 has changed to...
> 'A'== the absolute integer #1 has changed to...
> 'Z'== the "" #26 ...
> '`'== the relative .. #0 .. has changed by...
> 'a'== the relative .. #1 ...

... I'm not positive how many events are necessary, but I'd be
flustered if any *specific* I/O device generated more than 16 (2^4)
different classes of events. This means we can represent the
event as a 4-bit value. The way to determine event-type will be
device-type specific.

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

I've replied to someone else as to why I think timestamping of events
is really silly. Eliminating this trims out a whole 8 bytes.

> 3 bytes: the argument to the event:
> for booleans like keys, buttons, pedals, triggers: the number
> of that trigger. for absolute integers like joystick,
> lightpen, thermometers, the signed position. for relative integers
> like mice, trackballs, the signed displacement; this is a 18-bit value
> encoded in base 64 as above.

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.

> 1 byte: a signature "\n".

(Again, unnecessary, discussed elsewhere.)

To sum things up:

8 bits + 4 bits + 12 bits == 24 bits == 3 bytes.

The method I'm proposing would only require generating 3 bytes
per event, much less than your 16 bytes...

Some notes:

Human readability is unnecessary overhead. If this needs to be human
readable, write a small program that interprets the data into a
human-readable format. With the right API written for other programs
to take advantage of this system, a short program to generate
user-friendly output should be trivial.

> i don't know what to do about portability of scancodes. how about a
> unicode-like system of keyboard scancodes? i bet it exists... i think
> i've seen something similar once...

This will probably be ugly. But, fear not, someone's probably already
done this.

> once a device's output has been converted to this protocol, if the device
> is alone on the channel, it should get the number 0. if a mixer merges
> two signals, the packets must be time-sorted (as they would be
> separatedly), and one device becomes 1 while the other would stay 0.

Incoming data shouldn't need to be time-sorted. They don't come into
the system "in parallel" (although it pretty much *seems* like it) so
the data is already "sorted" for us. The system takes care of your
serializability issues.

My one *BIG* problem with this system is the fact that you wanted
to make all the data come out of one system device - that's *ugly*!
That means that *only* one application can read (and must read)
*all* the input from all your devices in this system. That renders
the whole concept useless.

Clearly, giving each device it's own major/minor numbers and a
separate /dev entry would be the way to go, and seeing as we can
only have 255 devices, we would only need 1 major number. Then,
applications could use devices through this generic system
interface...which would be really neat.

>From here, comes issues of two-or-more processes sharing the
same device (say, X and some other application sharing the
mouse). With this scheme, I don't see it as being possible...
am I missing something?

Well, that's my bit to try and help out with your efforts =).
Good luck, and keep me posted!

-Dossy

-- 
URL: http://www.panoptic.com/~dossy -< BORK BORK! >- E-MAIL: dossy@panoptic.com
    Now I'm who I want to be, where I want to be, doing what I've always said I
    would and yet I feel I haven't won at all...      (Aug 9, 95: Goodbye, JG.)
"You should change your .sig; not that the world revolves around me." -s. sadie

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu