> > 1 byte: a signature 'i'.
> (Unnecessary, already discussed elsewhere.)
Yes.
> > 1 byte: the device emitting the signal:
> > 1 byte: an ID matching /^[0-9A-Za-z]$/ case-sensitive numbering the
> 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.
Yes. Myself I think we could leave out the devicetype field at all.
> > 1 byte: describes the type of event happening:
> ... 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.
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
Which could fit into 3 or 2 bits, however, there is no real need to
save every bit we can, we have also to think about usage simplicity
and efectiveness of the interface. I think we shouldn't be splitting
fields in less than byte size.
> > 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.
Timestamping isn't silly, as I explain in another reply to you.
It's actually very much needed.
> > 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.
> 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...
But without important functionality, and with extra effort encoding
and decoding the data into anf from bitfields.
>
> 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.
It's already there and it's named 'hexdump' :) Or if this is not enough
comfort, there is 'jstest' for joystick devices ...
> 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.
Yes.
> > 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.
I think we could use much the same encoding that X uses - it would simplify
things quite a lot ...
> 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.
Well, incoming events can't be time-sorted. If an event arrives (which
the device generated earlier), and we've already sent out an event that
happened after the one we are just receiving ... we simply can't take
it back.
However, it is not true that there can't be events coming in reverse order.
There exist devices (MadCatz Panther XL, FPG Assasin 3D) that have their
own timestamps to make sure their events get the right time. With these,
you can receive an event that isn't happening *now*, but has happened in
the past ...
On the other hand, this is not a big issue, because the differences are
in the range of 10 ms maximum.
> 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.
This isn't true at all. A device can be opened my many applications
at once. This is no problem.
I agree with you, that forwarding all device events to all applications
that opened the device might be unnecessary overhead.
> 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.
Yes; I'm planning to do something like that. However, still the
more opens per device is needed, since there will be more than
one process that needs to read the keyboard, for example. :)
> >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. There is no problem with this. They simply open it both,
and both get the events. What problems do you see?
> Well, that's my bit to try and help out with your efforts =).
> Good luck, and keep me posted!
Have fun,
Vojtech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu