Re: User-space API for accelerometer(s)?

[Bastien Nocera <hadess@hadess.net>]

On Thu, 2014-07-03 at 18:51 +0100, Jonathan Cameron wrote:
> On 01/07/14 13:10, Bastien Nocera wrote:
> > Hey again Jonathan,
> >
> > On Sat, 2014-06-21 at 13:01 +0100, Jonathan Cameron wrote:
> > <snip>
> >> Just to throw it in there.  There is an out of tree bridge driver from
> >> IIO to input.  It's only out of tree because I haven't had a chance to
> >> tidy it up (anyone else is welcome to take this on if they like!)
> >> Google for iio_input.c to find it.
> >>
> >> The intent of that was to allow general accelerometer drivers and similar
> >> in IIO to work in conjunction with iio-input to provide input style interfaces.
> >> This came about after previous debates on where the 'right' place for
> >> accelerometers was in the kernel. I believe that at least in principle,
> >> Dmitry was happy with this concept.
> >
> > After updating forward-porting the driver so that it runs on a more
> > recent version of the kernel, I tried to get it running.
> >
> > I'm guessing that you expected the iio_input driver to be instantiated
> > by a board specific file. Is there any way to have it generically try
> > out all the IIO devices, similarly to pci_register_driver()? Or should I
> > do that in the hid-sensor-accel driver?
> At the moment we only have support to instantiate it via such a board specific
> file. We probably want to be a little careful about how to add more generic
> means for creating such bindings..
> 
> Simply generically trying all IIO drivers isn't the way to go as there is
> no obvious way of deciding what it makes sense to bind to on a given machine.
> 
> Perhaps something closer to the way you can instantiate i2c devices from
> userspace, or perhaps we need to consider something else such as configfs for
> creating such bindings... (cc'd Lars for comments on whether that makes sense...)

Are there cases where we have a hid-sensor that we wouldn't want to
expose through the input layer?

> We did also have a uinput based approach at one point but it was fairly clunky.
> That took data from iio buffers and pushed it back into the kernel via inputs
> userspace driver support. Not particularly nice but I thought I'd best mention
> it!

That's actually something that I looked at and discussed with Benjamin.
And it currently looks like the best possible solution in the short-term
(I will only have the machine for a couple more weeks...).

Cheers