----- Original Message -----
From: "Paul Koning" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, July 11, 2000 4:49 PM
Subject: Re: [Handhelds] Re: Touch Screen Driver Generic Interface for all
Linux SA11x0 platforms.
> >>>>> "Bradley" == Bradley D LaRonde <[EMAIL PROTECTED]> writes:
>
> >> ...
>
> Bradley> This is another reason why I think the best thing is to just
> Bradley> feed the raw data to userspace and divide it up there,
> Bradley> avoiding any attempt to calibrate or smooth data in the
> Bradley> kernel.
>
> I'd agree with that, provided you also get a query function that lets
> you discover what units are used for all those raw data items. That's
> a bit like X which gives you pixels (not world coordinates or
> millimeters or whatnot) but lets you find out how big the pixel is.
> (And unlike a certain other operating system which not only pretends to
> use inches, but then doesn't actually use the same size inches
> everyone else does.)
No, I mean send raw, unitless data to userspace.
> >> -- Timestamps are important because they allow pen velocity to be
> >> measured.
>
> Bradley> Agreed. Yet another reason for not munging things in the
> Bradley> kernel. Give every point to userspace so that all timing is
> Bradley> known.
>
> I can't tell whether you meant "have the kernel timestamp every point
> and give the result to userspace" or "have the kernel give every point
> to userspace so the application can do the timestamping".
>
> The latter won't work, of course...
The touch panel that I work with takes samples at regular intervals. If all
of those samples are delivered to userspace, then you can tell the timing of
data relative to other data, but not the absolute timing. I suppose the
kernel driver could put an absolute timestamp on every data point, but I
can't offhand see the usefullness in that, and it certainly would eat
kernel/userspace bandwidth. What would you need to compare any absolute
time against?
> >> -- Allow room for expansion to new data types in the API (for
> >> instance, pen pressure info). Translation: pad structures a
> >> little :-). I wouldn't want to try to overdesign this; that way
> >> lies X. I would at read a bunch of data sheets before trying to
> >> settle on a canonical API, though.
>
> Bradley> Userspace.
>
> Sure, though here in particular the need to query units is important.
> Also, I think you would want to linearize things, if the raw hardware
> has an oddball transfer function.
I'm saying that I think that all interpretation and distribution of the data
should be done in userspace, where it can be more easily engineered,
debugged, and extended.
Regards,
Brad
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
