On 10/04/2008, Daniel Stone <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 01:58:51AM +0200, ext andrzej zaborowski wrote: > > On 09/04/2008, Lauri Leukkunen <[EMAIL PROTECTED]> 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. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
