Messages in this thread |  | | From | rubini@pop ... | Subject | RFC: A generic pointer protocol | Date | 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 drivers.
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 mouse.
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...) iride.unipv.it:/pub/linux ftp.systemy.it:/pub/develop
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 /alessandro -- __ o La forza dei forti sta nel traversare le traversie con occhio sereno _`\<, (Paperino) __( )/( )__ alessandro.rubini@linux.it +39-382-529554
|  |