Messages in this thread |  | | Date | Thu, 14 Nov 1996 10:53:57 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: RFC: A generic pointer protocol |
| |
> rubini@pop.systemy.it wrote: > > > > 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).
An interesting proposal. Some comments:
You have a "buttons" bit field and coordinate fields, with X and Y being standard. This brings up the question of a pressure-sensitive tablet. Obviously pen pressure will be a Z coordinate. But how would an application know it is looking for Z instead of a button press. (Consider a fancy mouse might also have a Z that is just a thumb wheel, and not a button at all.)
I'd suggest having an additional integer field "pressure" and perhaps one called "color". "pressure" would contain the pressure used on a pointing device. On a mouse, this would simply be maximum if any button is pressed and minimum if no buttons are pressed. On a tablet, this would match the actual pen pressure in the Z coordinate. Thus, any program simply interested in whether the user is drawing something -- regardless of device in use -- can use the "pressure" field to determine this, without needing to know whether a coordinate or button is used to indicate the information.
"color" would be different for any different pen options (if the pen has an eraser, the eraser would be a different "color"). Probably the button field is sufficient for this.
Next I'd argue that getting precise (non-collected) pointer data could be very important. Any program which needs to record smooth pointer motion (like a good paint program) wants as high resolution data as possible. If you are doing something that needs _really_ high resolution (like handwriting recognition) you practically need the information to be recorded in an interrupt handler, with absolutely no losses.
Another issue is you mention scaling coordinates to 2^16. This is acceptable for a mouse, but misses the point completely on a digitizing tablet. There needs to be some way (perhaps not in the pointer-movement record, I'll admit) to let the user-program know that the device has an accurate real-world scale. (Actually, come to that, mice have accurate scaling factors too.)
Also, I'd hope the driver to implement this would allow for automatic delta-to-absolute conversions, and vice versa. A program should be able to request delta or absolute information and get it, regardless of connected device. (This also implies that the driver should support cropping limits on absolute devices, and should include ballistic algorithms for delta records. Having a single system-wide ballistic and speed-control feature seems like a sensible idea.)
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
|  |