Re: RFC: A generic pointer protocol
Fri, 15 Nov 1996 02:53:03 +0100 (MET)

This message concerns issues raised by Kenneth Albanowski and Albert
Cahalan, and Mark Cooke as well.

Kenneth Albanowski suggests:

> I'd suggest having an additional integer field "pressure" and perhaps one
> called "color".
> [...] interesting explanation removed

Hmmm... I'm doubtful. I'm currently adding a z-is-pressure flag,
but I don't like using the buttons as pressure indication. I plan
to have my Wacom tablet working within tomorrow, so I can test
things out. Unfortunately, I've no program sensitive to
absolute-pointing devices in addition to text mode selection :)

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

I'd better use the button field.

> Next I'd argue that getting precise (non-collected) pointer data could be
> very important.

Yes, I'm adding the possibility to select it by writing to the device
some control chatacters.

> Another issue is you mention scaling coordinates to 2^16.

Well, I'm turning to 2^30 (there's no performance loss, and more precision).

> This is acceptable for a mouse, but misses the point completely on a
> digitizing tablet.

I considered mapping the whole tablet to the whole screen. This is
what's needed for pointing pens (you point to the screen), but
actually won't work everywhere.

The basic point here is that usually such drawing software uses
a different pointer from the generic pointing device. You have
the mouse *and* the tablet. I have to think about supporting
multiple pointing devices -- it's not supported by now.

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

Client applications needing such information could write to the device
and get the range and precision information back (I'm adding support
for `special' packets, that ought to be ignored by unaware
applications). Another command could then select between
scaled/nonscaled operation. . Well, I've never seen such software, but
things should go well

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

Yes. By writing a command byte. "relative" output should be available
nonetheless in the /dev/kmouse (msc) node. "absolute" is available in
/dev/gpmctl node. No problem in letting the application select.

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

It's already there. /dev/kpointer has it already applied, /dev/rpointer
no (it's raw). The operations should be centralized as absolute
devices don't have ballistics.

Albert Cahalan pinpointed:

> The most I have ever seen is 6 dimensions _or_ 16 buttons. On the 6
> dimension controller, each dimension was really just a button pair.

Well, you're right. Since software should ignore the actual source
of information, too much information is a mess.

> I would recommend: 8 dimensions, 16 buttons, and an IOCTL used to
> get up to 4 kB of extra device-specific data.

Seems smart. The ioctl() maps to the physical device, which
can have a NULL pointer in its entry. This can be done rightahead,
as device protocols are already add-on items.

> It is very important to maintain the order of key presses and mouse
> clicks.

This can't be done with my tool. The sparc input system and GGI have
a unified input stream. I'm going to look in them.

> but we can survive without that.



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