On Mon, Sep 21, 2015 at 2:46 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > On 21/09/15 15:26, Mike Mestnik wrote: >> On Sep 20, 2015 5:42 PM, "Bastien Nocera" <hadess@xxxxxxxxxx> 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@xxxxxxxxx> wrote: >>>>>> On Fri, Sep 18, 2015 at 12:07 AM, Mike Mestnik < >>>>>> cheako@xxxxxxxxxxxxxxx> 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 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. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
