Hi, On 09/04/2008, Lauri Leukkunen <lauri.leukkunen@xxxxxxxxx> wrote: > On 09/04/08 21:05 +0300, ext Felipe Balbi wrote: > > On Wed, Apr 09, 2008 at 07:26:31PM +0200, andrzej zaborowski wrote: > > > > Question not really related to this patchset, but in the TSC2005 > > > driver some averaging and limit checks are done to the ADC values. > > > Shouldn't that be done in userspace instead? (The ADS784x and TSC2301 > > > drivers do the same evidently.) > > > > Now that's not really up to me, but if we move it now it probably won't > > provide the feature n810 needs. I mean, n810 is designed on top of the > > features provided by driver, the application probably expects the driver > > to do the averaging and limit checks so at least for tsc2005 I think > > it's not a good idea to change due to application requirements. > > > User-space is too late for this filtering, we would end up feeding ~1k samples > per second there, and that would simply clog the system pretty badly, can't > do much buffering either as that degrades interactive responsiveness of the > UI. That's true, that'd send to userspace the amount of data multiplied by the number of samples over which the averaging is done. I don't know how significant amount that would be. > In my opinion kernel should provide "correct" data to user-space, not > some pseudo-random interference from the LCD. I think this is discutible. There's a number of userspace libraries written to talk tightly to the kernel and make that data more "correct", one of them is tslib. Distros that come with tslib often have a set of device-specific config files for tslib which load tslib plugins for things like averaging, smoothing, checking bounds on the values. One of the arguments for doing that in userspace is that of avoiding every touchscreen driver redoing the same averaging and/or limit checking code. I agree thought that it may be better to sacrifice that for performance. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html