I have a whole format an artist and I designed in 1994 for a game. the
program was made in QuickBASIC but the format was so full of bitfields
that we should have considered rewriting everything in C at that point.
> 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.
this smells like major/minor numbers at a lower scale... 0.3 design
decision: 4 bits each, and anyway it isn't *that* useful, because most
streams will contain only stuff from *one* device anyway.
> > 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.
restating my stuff in another way, three types of events are necessary,
and here are pseudocode function signatures corresponding to them:
abs_int_changed (index in range 0..255, newvalue of type short);
rel_int_changed (index in range 0..255, movement of type short);
bool_changed (index in range 0..255, newvalue in range 0..2);
where the value 2 as the 2nd parameter of bool_changed means that it's an
automatic repeat event coming from the keyboard.
and let's add a 4th one just in case:
special_stuff (whatever);
unifying all of those signatures, this leaves us with 2 bits for the type
of event. the rest is left to be determined.
> 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.
it's now 6 bytes, and could drop to 4 bytes if i drop the long-term
considerations (system latency shouldn't be higher than 65536 seconds or
there is something really wrong...) so each event won't unnecessarily
store years, months, weeks, and even days.
> 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
but : there are more than that Key Variations. There are, on a typical
Sun Sparc-5 keyboard, over 15 keys with no equivalent on a PC: Help, Cut,
Copy, Paste, Find, Open/Close, Stop, Front, Undo, Again, Props,
Speaker[+], Speaker[-], Speaker[On/Off], Suspend. Add up all such
variations and you're over 128 alot, maybe over 256.
> 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.
okay, this is part of my 0.3 proposal now:
A B C D
|| |||||| |||||||||||||| ||
these are four zones of 2, 6, 14, 2 bits.
zone A is always the event type: relint, absint, bool, special.
in relint and absint, the B is the index, and CD (C*4+D) is the new value
or the movement.
in bool, it's BC (B*16384+C) that is the index, and D that is the value.
in special, it's not defined yet.
> 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.
that's taken in account at proposal 0.2, written yesterday. :-)
> > 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.
Well, I knew there was one: The xkb / Xserver is, to a certain point.
> 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*!
no, this will be handled as the administrators and programmers wish. It
will normally be operated on separate channels, but one is able to merge
them, hence the device ID's.
> 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?
Yes. If you want to share devices, you create a filter that will split
output, similar to 'tee'.
> Well, that's my bit to try and help out with your efforts =).
> Good luck, and keep me posted!
matju
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu