Messages in this thread |  | | From | rubini@pop ... | Subject | Re: RFC: A generic pointer protocol | Date | Mon, 18 Nov 1996 05:11:05 +0100 (MET) |
| |
> The main problem with tactile feedback is that the data goes from the > application to the device and not the other way around.
I understand.
> [...] > but I'd need to know more about the hardware than I currently do to give > a definitive answer.
And this is very device specific. There's no need to give feedback for normal uses of the pointer. I don't think this could be supported by a general protocol or not this yeat, at least.
> I don't like the idea of a "device-specific" extension for something so > broad because that seems to eliminate the purpose for creating such a > standard.
Yes and no. If you just want pointer information you use the general protocol; if the application is bound to the hardware pointer, it can use explicit features of the pointer. But I'd like to be able to move the X mouse cursor by moving my head if I have such a digitizer. Applications using more dimensions will use them from the generalized kernel pointer, independently of how the information is generated. For example, an inclination-sensitive tablet can report 5 dimensions: why not using it in place of a real cloche if I don't have a cloche?
Nonetheless, if the applications can speak directly to the device through kpointer, they won't open the device *instead*of* the kernel pointer, and there's no loss of generality. Similarly, you use read and write to access every device file, but you have device-specific ioctl's to to access additional features.
Best, /alessandro -- __ o La forza dei forti sta nel traversare le traversie con occhio sereno _`\<, (Paperino) __( )/( )__ alessandro.rubini@linux.it +39-382-529554
|  |