lkml.org 
[lkml]   [1996]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RFC: A generic pointer protocol
Date


> 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

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.026 / U:1.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site