lkml.org 
[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: uniform input device packets?
On Tue, Jun 23, 1998 at 05:59:51AM -0400, Mathieu Bouchard wrote:

> 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.

I've been thinking about much the same thing myself.

> A packet could be:
>
> 1 byte: a signature 'i'.

Is this needed? If we are reading this device we already know what
we expect in there.

> 1 byte: the device emitting the signal:
> 1 byte: an ID matching /^[0-9A-Za-z]$/ case-sensitive numbering the
> 1 byte: describes the type of event happening:
> 8 bytes: a base64 (32 through 95) timestamp containing a 32-bit value
> 3 bytes: the argument to the event:
> 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 quite like the protocol. However, is it really needed to be base-64
encoded? I don't think the human readability is such a big plus to allow
this overhead in the kernel.

> 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...

Well, this isn't an easy issue. All the boolean and even the integer
events should be possible to identify by the application receiving the
events, eg. we could use the number 'a' for a 'A' key on a keyboard -
but what to use for the left mouse button? And how to say to the application
which integer event is up/down, and which right/left? And joysticks ...
there is a lot of very different sticks, with 2-9 integer outputs,
using them for various purposes ... these should be somehow identified,
too ... any ideas?

Or we could just leave setting this to the user, as is currently done
with the keyboard via loadkeys ... having a similar map somewhere and
a library that reads it.

> 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.

I don't think we can time sort packets. This would imply buffers, which
could be huge to keep the packets sorted. And, what would we do upon receiving
an older event from a low-level driver that the one we already sent to the
application?

> a mouse would use these: booleans 1 to 5 (for buttons 1 to 5); Relat.#0
> is X displacement; Relat.#1 is Y displacement.

What about mice with scroll wheels? And 6DOF devices used in CAD design?
The protocol could handle them, but these assignments couldn't be valid
anymore.

> a joystick would be quite the same, except Absol.#0 and Absol.#1 would be
> used instead.

Well, for joysticks you'd need at least 10 booleans for buttons and about
the same number of integers ...

By the way, the protocol is missing a way how to get info on what range
of integer/boolean events the device can generate ...

> a keyboard would use lots of booleans, and nothing else.

Yep.

> 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).

Yes, it could. But I don't think the protocol is matching these uses ...

> 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.

Eek. Do you want it to control spaceships, too? What about throwing
away TCP/IP and control the whole internet with this? Keep things simple,
please. And remember that a couple of specific tools is usually much better
than a single super-swiss-knife with inbuilt calculator and rocket launcher.

> 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...

After all, as I said in the beginning, I like it. I would simplify it a bit,
though. Would make it unidirectional only, kernel->application, architecture
specific (endianity), binary, unencoded (no base64), with a bit less fields,
with ioctls for all the non-event info, but, otherwise, much the same. :)

Vojtech

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.069 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site