4 bits each limits you to 16 types of devices - I'm willing to bet that's
more likely to be exceeded than more than 8 of any one *type* of device.
I'd say 3/5 is the better split.
And, as Vojtech mentioned, if we give each individual device it's own
minor number, the device id/type is totally redundant. Scrap the whole
byte from the spec.
> 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);
What exactly does "index" refer to?
> where the value 2 as the 2nd parameter of bool_changed means that it's an
> automatic repeat event coming from the keyboard.
Isn't that what bool_changed==false means? *boggle*
> > 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.
Timestamping with granularity of whole seconds would be totally pointless
for the most part. They would best be in hundredths of seconds, or even
in milli- or micro-seconds. Can we actually *have* micro-second level
granularity accurately? *shrug* For most devices that actually NEED
to pay attention to event timestamps, hundredths of seconds is probably
sufficient - but don't quote me on that. Still, we'd want to be able
to go anywhere from .01 seconds up to probably ~60 seconds. A 2-byte
value for a timestamp should be sufficient, in any case.
> > 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.
How many unique scancodes can the sun5 keyboard generate? Certainly
not 2^128 (!). A keyboard with 128 keys (in *my* own twisted sense
of intuition) shouldn't be able to generate more than 128 scancodes.
Keys never generate events "simultaneously" (well, in parallel)...
they may happen very close together, but still happen one after
another. All a keyboard needs to do is send change-of-state
information, and from there we can "interpret" what keys are being
pressed simultaneously and so-on. I doubt any keyboard is going
to have more than 255 keys (of course, soon enough I'm sure someone
will prove me wrong =P... but who'd *use* such a device? =) ).
> > 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.
2 bit event, 6 bit index, 16 bit value
> in bool, it's BC (B*16384+C) that is the index, and D that is the value.
2 bit event, *20* bit index, 2 bit value?
Overkill, but heck, we'd have to pad bits anyhow.
Where'd your timestamp go? Others are lead to believe that it's
necessary - throw an extra 2 bytes into that for your timestamp.
It brings you up to 5 bytes. Not *bad*.
> > 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.
Lets drop the device ID's, and give each individual device a unique
identifier outside of the protocol stream. If someone wants to merge
devices, let them just open multiple devices at once. Don't make
every other application pay for the overhead that would be required
to also have everything fed from the same source. For most cases,
that's unnecessary. For the degenerate cases, they can just open
all the various devices themselves. Perhaps have a "device class"
device, that serves events for all devices of a particular type...
but even that's flaky.
-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