Re: [PATCH] Asus T300CHI.

[Mike Mestnik <cheako@mikemestnik.net>]

On Sep 20, 2015 5:42 PM, "Bastien Nocera" <hadess@hadess.net> wrote:
>
> On Sun, 2015-09-20 at 20:08 +0100, Jonathan Cameron wrote:
> > On 19/09/15 20:03, Mike Mestnik wrote:
> > > On Sat, Sep 19, 2015 at 1:48 PM, Daniel Baluta <
> > > daniel.baluta@gmail.com> wrote:
> > > > On Fri, Sep 18, 2015 at 12:07 AM, Mike Mestnik <
> > > > cheako@mikemestnik.net> wrote:
> > > > > Hello,
> > > > >   I'm looking to know the result of adding ACPI support for a
> > > > > new
> > > > > tablet, the existing support shouldn't work because of a
> > > > > misplaced
> > > > > __init that causes the function to be removed prior to being
> > > > > called.
> > > >
> > > > Are you sure about this? It seems that the existing support
> > > > doesn't work
> > > > because you have different product ids.
> > > >
> > > The driver worked much better prior to me adding the product ids.
> > >  The
> > > sensors were exposed to sysfs and all the data they collected
> > > seemed
> > > correct to me.  The big issue is that there is no software, even
> > > iio-sensor-proxy didn't know how to access the data.
> > Cc'd Bastien Nocera.
>
> iio-sensor-proxy not finding the sensor, and with it working otherwise,
> would be an iio-sensor-proxy bug. I have one of those already for the
> accelerometer in the WinBook TW100 that I haven't had time to root down
> though. See:
> https://github.com/hadess/iio-sensor-proxy/issues/39
>
> The main problem being that sensor types are already hard to detect,
> and the iio subsystem doesn't make it any easier to check whether
> there's buffered output available, or the application needs to poll.
>
> If anyone wants to fix that in the kernel, that would certainly make my
> life easier.
>
I only kind of understand the reasoning for iio, but for the case of
devices used for instructing application behaviour I can't help but think
this would be better served using/extending input events.

That would seam to cover the above issues, in exchange for having to add
support for a few new tricks.

1. An axis where max and min are actually one 'step' apart.
2. Double axis for xyz, 6 instead of 3.  Perhaps this can be handled with
extra event nodes, but then there may be sync issues.
3. Integrating iio data into input events.  I don't even understand what
this would mean.

> Cheers