From: Andy Green <andy@warmcat.com>
To: arhuaco@freaks-unidos.net
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
dtor@mail.ru, Shine Liu <shinel@foxmail.com>,
dmitry.torokhov@gmail.com,
Maurus Cuelenaere <mcuelenaere@gmail.com>,
linux-input@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] input/touchscreen: add S3C24XX SoC touchscreen input driver
Date: Tue, 20 Oct 2009 11:09:07 +0100 [thread overview]
Message-ID: <4ADD8C43.5060205@warmcat.com> (raw)
In-Reply-To: <2accc2ff0910200121g4f2c0839l96c7d99e4f4de47a@mail.gmail.com>
On 10/20/09 09:21, Somebody in the thread at some point said:
> We have problems when we don't have much pressure and in this case
> there is a lot of noise and the events that are reported by the driver
> are actually noise. This noise would be more common at pen-down before
> the adc readings settle and at pen-up.
Hi Nelson -
Just a FYI, on the board I have been working on there is a capacitive
sensor, AD7174. I wrote a driver for it which again uses the in-kernel
median filter (the original Openmoko version I wrote chopped out at the
moment) heavily and with really excellent results. The median filters
are pretty much like magic for certain common kinds of noise.
However, I just drop the median filter code into my tree in
drivers/input/misc at the moment. What would be really a good result I
think is if the filters turned up in ./lib in an easily reusable way.
I think maybe it's a mistake to focus on the in-kernel filters being
good for a particular touchscreen technology or even specifically
touchscreens. I am sure other drivers doing something completely
different with noisy instantaneously sampled data, that won't fit into
tslib worldview at all, can also benefit from being able to clean up
data in a standardized way before passing it down as an input event or
back to the device or whatever. And once that's possible, touchscreen
drivers of any sort have the standardized option to use it too if they
have a reason.
Just a thought, good luck :-)
-Andy
WARNING: multiple messages have this Message-ID (diff)
From: andy@warmcat.com (Andy Green)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] input/touchscreen: add S3C24XX SoC touchscreen input driver
Date: Tue, 20 Oct 2009 11:09:07 +0100 [thread overview]
Message-ID: <4ADD8C43.5060205@warmcat.com> (raw)
In-Reply-To: <2accc2ff0910200121g4f2c0839l96c7d99e4f4de47a@mail.gmail.com>
On 10/20/09 09:21, Somebody in the thread at some point said:
> We have problems when we don't have much pressure and in this case
> there is a lot of noise and the events that are reported by the driver
> are actually noise. This noise would be more common at pen-down before
> the adc readings settle and at pen-up.
Hi Nelson -
Just a FYI, on the board I have been working on there is a capacitive
sensor, AD7174. I wrote a driver for it which again uses the in-kernel
median filter (the original Openmoko version I wrote chopped out at the
moment) heavily and with really excellent results. The median filters
are pretty much like magic for certain common kinds of noise.
However, I just drop the median filter code into my tree in
drivers/input/misc at the moment. What would be really a good result I
think is if the filters turned up in ./lib in an easily reusable way.
I think maybe it's a mistake to focus on the in-kernel filters being
good for a particular touchscreen technology or even specifically
touchscreens. I am sure other drivers doing something completely
different with noisy instantaneously sampled data, that won't fit into
tslib worldview at all, can also benefit from being able to clean up
data in a standardized way before passing it down as an input event or
back to the device or whatever. And once that's possible, touchscreen
drivers of any sort have the standardized option to use it too if they
have a reason.
Just a thought, good luck :-)
-Andy
next prev parent reply other threads:[~2009-10-20 10:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.4020.1255949705.2256.linux-arm-kernel@lists.infradead.org>
2009-10-19 11:28 ` [PATCH] input/touchscreen: add S3C24XX SoC touchscreen input driver Maurus Cuelenaere
2009-10-19 11:28 ` Maurus Cuelenaere
2009-10-19 12:07 ` Russell King - ARM Linux
2009-10-19 12:07 ` Russell King - ARM Linux
2009-10-20 4:21 ` Nelson Castillo
2009-10-20 4:21 ` Nelson Castillo
2009-10-20 7:39 ` Russell King - ARM Linux
2009-10-20 7:39 ` Russell King - ARM Linux
2009-10-20 8:21 ` Nelson Castillo
2009-10-20 8:21 ` Nelson Castillo
2009-10-20 9:41 ` Mark Brown
2009-10-20 9:41 ` Mark Brown
2009-10-23 5:38 ` Nelson Castillo
2009-10-23 5:38 ` Nelson Castillo
2009-10-20 10:09 ` Andy Green [this message]
2009-10-20 10:09 ` Andy Green
2009-10-19 13:31 ` Shine Liu
2009-10-19 13:31 ` Shine Liu
2009-10-19 14:44 ` Arnaud Patard
2009-10-19 14:44 ` Arnaud Patard (Rtp)
2009-10-19 14:34 ` Juergen Beisert
2009-10-19 14:34 ` Juergen Beisert
2009-10-19 10:54 Shine Liu
2009-10-19 10:54 ` Shine Liu
2009-10-20 1:38 ` Dmitry Torokhov
2009-10-20 1:38 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ADD8C43.5060205@warmcat.com \
--to=andy@warmcat.com \
--cc=arhuaco@freaks-unidos.net \
--cc=dmitry.torokhov@gmail.com \
--cc=dtor@mail.ru \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mcuelenaere@gmail.com \
--cc=shinel@foxmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.