* andrzej zaborowski <balrogg@xxxxxxxxx> [080409 18:12]: > On 10/04/2008, Daniel Stone <daniel.stone@xxxxxxxxx> wrote: > > On Thu, Apr 10, 2008 at 01:58:51AM +0200, ext andrzej zaborowski wrote: > > > On 09/04/2008, Lauri Leukkunen <lauri.leukkunen@xxxxxxxxx> wrote: > > > > > > 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. > > > > > > If everyone's doing the same thing, move it to drivers/input/, not to > > userspace. Why should we be forced to have _two_ drivers and > > essentially maintain a stable kernel/userspace ABI between them? Surely > > it's better to only have _one_ hardware-specific driver, rather than > > half in the kernel, and half hidden behind an abstraction layer that is > > meant to let you just deal with input events without knowing stupid > > details about the hardware? > > For the ease of reconfiguration for one thing, tslib is quite > configurable with the plugins loaded by a config file. The ABI you > talk about is the same evdev ABI which is already stable. > > Averaging doesn't just cancel the noise from LCD, just lessens it but > there may be better things to do with it and the userspace already > knows how to deal with that. So it expects the kernel driver to be > more like a ADC driver. > > Of course doing it in drivers/input/ as configured by board files, > would also work if things were designed that way. Where to do the filtering should be discussed with the input people. Meanwhile, I'll push this patch to linux-omap tree. Tony -- 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
