RFC: A generic pointer protocol

Wed, 13 Nov 1996 21:23:37 +0100 (MET)

Hello Linuxers,
this is a proposal for a new pointer protocol, which should
solve most problems with pointing devices. Please pardon me for the
bandwidth. This message explains the theory; who wants to try an
implementation and more extensive docs can look at kmouse-0.45 (see at
the end).

The basic idea is that applications want to retrieve sound information
from pointing devices, and don't want to care with the different pointer
protocols. The first approach to this has been "gpm", but such solution
features some bad limits: mainly a poor performance and a limited
number of supported buttons/dimensions.

New pointing devices (pens, tablets and 3D devices) demand for a new
generalized protocol. If X supports this protocol, a few lines of code
will suffice to use any pointing device with X -- the problem applies
for example to some laptops equipped with a custom pointing pen: it's
much easier to load a kernel module than changing the whole server.

The protocol I'm proposing is extensible up to 16 dimensions and 16
buttons. If this is not considered enough, the protocol can
be changed -- it's not an established standard, yet :). Any
application supporting this protocol wouldn't need upgrading to
support a new pointing device.

The Protocol

The basic packet is the following:

typedef struct Kmouse_Packet {
__u8 magic[2]; /* two bytes to identify the packet head */
__u16 flags; /* relative/absolute, available butn's and dmn's */
__u16 buttons; /* many buttons available */
__u16 shift; /* the keyb modifiers when at the event's time */
__s32 x;
__s32 y;
__s32 z[0]; /* extra coordinates */
} Kmouse_Packet;

Data transfer is only accomplished in multiples of 4 bytes, and the
device returns data in native-endian mode. This should avoid
unnecessary conditionals and byte-swapping. The first longword tells
how many dimensions are supported, so the application can
read the rest of the packet.

Absolute positions (like those reported by pens or tablets) are
normalized in the range 0-65535. Values outside this range are used to
represent out-of-screen coordinates. The decoding application knows if
the device is absolute or relative from the "flags" field. 64k pixels
in either direction should be sufficient for every graphic display.

Other Proposed Features for the Kernel Pointer

The pointer should be vc-specific: a pointing device is part of the
console interface, so applications on different console should be able
to open /dev/kpointer independently. This is the main reason why a
user space solution is difficult to achieve. This also overcomes the
single-open problem with busmice without adding complexity to the

Successive motion events should be clustered whenever possible: an
application reading the pointing device wants the `current'
information, not the past history of movements. Obviously, button
press/release events won't be eaten by clustering. This can greatly
help performance in a loaded environment and is the second main
reason to use a kernel driver.

Old programs able to read serial mice (like X) and gpm clients (like
mc) should be able to run with the new pointer. Thus two devices
(/dev/kmouse and /dev/gpmdata) are needed to comply with the old
protocols. Programs linked with libgpm-1.0 (mid 1995) and later won't
notice the difference.

New drivers for new pointing devices should stack on the kernel
pointer to feed their events to the central repository.

Multiple pointers should be able to feed /dev/kpointer. This is needed
for owners of a trackball-equipped laptop who prefer using an external

Unused pointer events should run the selection mechanism.

An external program should be used to configure the pointer devices
at boot time, but a minimum autodetection of the protocol would help.

Sample Code

Kmouse-0.45 implements the features described above (but only for
Linux-2.0.x), and can be retrieved from any of the following places:

tsx-11.mit.edu:/pub/linux/ALPHA/kmouse (currently in incoming...)

Currently the module only supports the "ms" and "msc" mouse protocols,
and no busmouse. The Z coodinate(s) isn't supported as well and
absolute-pointing devices aren't fully supported. These problems are
being worked on, as I've been loaned a Wacom tablet (absolute & 3d).

Feel free to send me your opinions/flames.

Best regards

    __ o La forza dei forti sta nel traversare le traversie con occhio sereno
   _`\<,                                                        (Paperino)
__( )/( )__     alessandro.rubini@linux.it  +39-382-529554