Messages in this thread | | | Date | Wed, 24 Jun 1998 02:23:35 -0400 | From | Allanah Myles <> | Subject | Re: uniform input device packets? |
| |
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
| |