A touchscreen driver has been posted upstreams
joerg at openmoko.org
Tue Nov 24 20:28:15 CET 2009
[Nelson Castillo Di 24. November 2009]:
> On Tue, Nov 24, 2009 at 10:43 AM, Werner Almesberger
> <werner at openmoko.org> wrote:
> > Nelson Castillo wrote:
> >> What I understood from this thread is that filtering has to be done in
> >> user-space and that drivers should send unfiltered sets of points at a
> >> higher rate.
> > ... or that you (or someone) has to prove clearly that this is one
> > of the things you can't do properly in user space, e.g., because
> > the processing required would exceed the systems's capabilities.
To me this seems to be a clear case for a kernel driver task.
a) want to have kernel hardware interfaces (devices) that are as untroubled as
feasible by particular hw device properties and peculiarities (a ts is a ts
is a ts [is a pointerdevice]), and
b) the whole filtering is to *fix* a *bug* in ts-hw, as jitter is no generic
or even desired property of a touchscreen and userland never will be
interested in jitter.
So if userland ever would need to tweak kernel filtering of ts, this is solely
due to the fact the kernels job of filtering isn't performing good enough to
filter really just jitter and nothing else.
If we want to have a most uniform userland across all platforms, this is a
An even stronger point in a broader view is userland has no idea of the actual
cause of jitter, so it never can perform as good as kernel may. Who knows if
we might find tomorrow jitter can be fixed by disabling the backlight
converter for the 5 ms of ts-A/D-conversion - or any other means userland has
no idea how to ever accomplish it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20091124/6741755d/attachment.pgp
More information about the openmoko-kernel