On Mon, Oct 19, 2009 at 01:28:13PM +0200, Maurus Cuelenaere wrote:
> Do you know that there's another patch (at Openmoko) created by Nelson
> Castillo that does the same, but also has support for kernel-space
> touchscreen filters? (I think [1] is his latest version)
> I don't know how your patch performs, but according to [2] the filters
> should help a lot avoiding jitter etc.
>
> I'm not sure whether Nelson has submitted his patches for mainline
> review yet and what the status is on the kernel filters, but IMHO doing
> some filtering in kernel space (see the "Why are we doing filtering in
> kernel space?" part of [2]) which results in a "cleaner" output is
> preferred over reporting possible "jittery" data.
It doesn't really describe why doing the filtering in kernel space is
apparantly soo much better than doing it in tslib - it's seems to just
do some handwaving kind of argument:
Let's say we would like to deliver a TS event to user space each 10
milliseconds. In the GTA02 with the current configuration the
Analog/Digital conversion time of a sample is 0.4697 milliseconds, thus
can get 18 samples for each event that we send to user-space. Sending the
event (with 18 samples) takes us about 8.45 milliseconds.
So far so good. But, according to my maths, 8.45ms is less than 10ms.
Sometimes we
even decide that the event should not be sent to user-space (because the
hardware didn't provide reliable data), and our tests show that it's the
right thing to do. In previous versions of the driver light taps would
confuse the driver (that would report bad clicks) and this is no longer an
issue.
Err, that doesn't seem to follow on from the previous point.
The reason that we decided raw events should be passed to userspace and
the processing done there is that it allows all of the _policy_ of
deciding how to process touchscreen events to be configured. There's
lots of different parameters and ways to filter touchscreens, and some
are specific to individual touchscreen setups.
This is why tslib is entirely modular, and allows any combination of
modules to be loaded to process the touchscreen samples - it's there
to provide a totally flexible infrastructure to filter and scale
the output from the touchscreen in whatever way is required for the
hardware.
I don't think there is any single filtering system which can properly
filter the output of any one touchscreen, and I don't think that putting
this filtering in the kernel is a sane approach. It _may_ be a sane
approach for one particular touchscreen setup, but it certainly isn't
for all.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
