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