Re: [PATCH 1/5] I2C: LM8323: Introduce lm8323 keypad driver

[Tony Lindgren <tony@atomide.com>]

* andrzej zaborowski <balrogg@gmail.com> [080409 18:12]:
> On 10/04/2008, Daniel Stone <daniel.stone@nokia.com> wrote:
> > On Thu, Apr 10, 2008 at 01:58:51AM +0200, ext andrzej zaborowski wrote:
> >  > On 09/04/2008, Lauri Leukkunen <lauri.leukkunen@nokia.com> 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