here is a sample of what could be done to unify keyboard, mouse, etc.
input into a single protocol. this includes the realtime needs described
recently... as well as a possible need for a /dev/keyboard (according to
me!?).
i envision: this protocol would be used by the kernel and/or daemons
and/or user processes, with sysv-pipes and/or char-devices and/or
bsd-sockets. support for such mouse and keyboard input would be included
in X, svgalib, dosemu, etc.; the mouse and keyboard inputs need not to be
in the same stream, but are allowed to do so.
A packet could be:
1 byte: a signature 'i'.
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.
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 ...
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)
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.
1 byte: a signature "\n".
I designed it to be fairly efficient while being human-readable through a
'cat'. this accounts to 16 bytes. the stuff is easy to decode (btw, it's
all big-endian, but this shouldn't affect performance really as the stuff
would have to be decoded anyway), and shouldn't take too many
instructions for doing so.
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...
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.
a mouse would use these: booleans 1 to 5 (for buttons 1 to 5); Relat.#0
is X displacement; Relat.#1 is Y displacement.
a joystick would be quite the same, except Absol.#0 and Absol.#1 would be
used instead.
a keyboard would use lots of booleans, and nothing else.
a thermometer would only use Absol.#0.
the same generic protocol could be used to talk to those input devices
(like to ask them a complete restatement of their status, or configure
mouse acceleration, keyboard repeat rate, etc).
the same generic protocol could be used to talk to devices like
robots/turtles, lights, VCR's, audio CD players, amplifiers, house
environment in general, auto-power-on/off timers for computers, etc.
any comments? I intend to keep it relatively simple. i'd like to hear
lots of ideas and though i would probably like most of them, i would like
to keep it simple enough so that applications don't face a complex
protocol (see: X11 protocol). I would like to know whether _you_ would
like it, whether _you_ would like something more efficient or more
user-friendly...
that's it.
matju
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu