Re: [PATCH] Asus T300CHI.

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

On Thu, 2015-09-24 at 10:57 -0500, Mike Mestnik wrote:
> On Mon, Sep 21, 2015 at 2:46 PM, Jonathan Cameron <jic23@kernel.org>
> wrote:
> > On 21/09/15 15:26, Mike Mestnik wrote:
> > > 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.
> > I dispute this one.  It's not exactly hard to check for the buffer
> > directory in sysfs and to evaluate if there is a trigger provided
> > by
> > the device (again a simple directory presence check).
> > It gets harder if there is more than one trigger provided, but
> > inherently
> > there isn't much we can do to suggest the best one.  If there are
> > two
> > then there are two usecases that demand different choices.
> > 
> > > > 
> > > > 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.
> > Indeed, the IIO side of things is about providing generic support
> > for lots of use cases whereas in your case you are looking at
> > something
> > which is naturally quite specific.
> > 
> I just found a copy of this driver in the input tree:
> drivers/input/misc/mpu3050.c
This was done in 2011 time frame, when IIO was still in staging, I
guess.
Using input driver is not good idea as we need some special sysfs
entries for control.
There was some proposal for IIO input driver bridge.

Thanks,
Srinivas

> Perhaps "indexing" drivers by userspace API is the wrong approach as
> it's logical that a device my be accessible from userspace via
> multiple APIs and applicable for lots of reasons.  Splinting drivers
> into directories because of how userspace communicates with the
> driver
> is just asking for duplication or problems with bringing in the
> appropriate code.
> 
> > > 
> > > 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.
> 
> At first glance it seems that these are still outstanding, needing a
> proposed userspace API.