From mboxrd@z Thu Jan 1 00:00:00 1970 From: arhuaco@freaks-unidos.net (Nelson Castillo) Date: Fri, 23 Oct 2009 00:38:26 -0500 Subject: [PATCH] input/touchscreen: add S3C24XX SoC touchscreen input driver In-Reply-To: <20091020094132.GA17240@sirena.org.uk> References: <4ADC4D4D.5020508@gmail.com> <20091019120744.GB7412@n2100.arm.linux.org.uk> <2accc2ff0910192121t27387b90t9cfd5a5252aa00cc@mail.gmail.com> <20091020073946.GB723@n2100.arm.linux.org.uk> <2accc2ff0910200121g4f2c0839l96c7d99e4f4de47a@mail.gmail.com> <20091020094132.GA17240@sirena.org.uk> Message-ID: <2accc2ff0910222238g31161deoe704a889df3c4b3a@mail.gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Oct 20, 2009 at 4:41 AM, Mark Brown wrote: > On Tue, Oct 20, 2009 at 03:21:17AM -0500, Nelson Castillo wrote: > >> Can the s3c driver send the events at full speed? (Maximum possible ADC rate?). Yes, but in packets I think (The way I would know how to implement it). We could try sending 2000 events per second to user-space and see what happens :-) :-) >> Even if it's possible I think we would monopolize the adc driver >> needlessly because we don't need all that conversions when there is >> not much noise. Please read on. > > There's currently no facility to push sample rate requests down into the > kernel from userspace. ?However, this is a good idea in general - there > was some recent (brief) discussion of doing this on the linux-input list. I see. It makes sense. ATM one big difference with the kernel approach is that in the kernel you can request the adc conversions on demand. > Since different use cases have different sample rate requirements (such > as the difference between handwriting recognition which can need 200 > samples/second and a simple finger operated menu which may be happy with > 10) there's value in being able to vary the sample rate at run time. ?I > was intending to look at this shortly as part of some touchscreen driver > development I need to do soon or perhaps someone else will pick up the > idea, if it does get implemented then obviously tslib would also be able > to use it here. With a lot more points you can indeed do better filtering in users-pace.