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)