On Fri, Sep 25, 2015 at 9:19 AM, Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote: > On Thu, 2015-09-24 at 10:57 -0500, Mike Mestnik wrote: >> 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 > 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. It has a configurable trigger and several power levels depending on the events needing to be generated. > There was some proposal for IIO input driver bridge. > Testing for this driver isn't as promising as the iio. I'm getting a better feel for talking to this device and implementing the hardware side of a driver. Though I've no direction for implementing the userspace api, see below. > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
