--- Top Post --- I've done some more research into this and I feel that the iio project has the answer, the kernel api. Looks like the developers of iio had already considered input events being generated from iio data, this includes both rotation(6 possible states and reasons other than an ~0,0 pivot) and mouse like movement. Thus I feel that devices/input/iio-sensors should replace a userspace process like iio-sensor-proxy for all the reasons I've previously stated. For the mpu6050 this would mean at least two more event devices, when activated ideally the iio interface would "dry up" to avoid contention. As stated I feel that the current detection for rotation leaves a lot to be desired when compared to how an android opperates, but even they didn't get it right. The pice of the puzzel lacking is the pivot point of the rotation, if it's about 0,0 then the screen should flip. However if the distance from 0,0 of the pivot point is the distance to a persons hind end then the user is simply lying down and the head to screen orientation does not change, thus rotating the screen is in error. There are other notable non 0,0 pivot points and in these cases it's also likely that rotating the screen would be incorrect. I'm off to work another project, but if i find the time this is high on my todo list. Cheers. On Tue, Oct 20, 2015 at 6:55 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > On Tue, 2015-10-20 at 06:52 -0500, Mike Mestnik wrote: >> >> On Oct 20, 2015 4:53 AM, "Bastien Nocera" <hadess@xxxxxxxxxx> wrote: >> > >> > On Tue, 2015-10-20 at 08:39 +1000, Peter Hutterer wrote: >> > > On Mon, Oct 19, 2015 at 12:20:27PM -0500, Mike Mestnik wrote: >> > > > Hello, >> > > > I've been working on a project called iio-sensor-proxy, it's >> a >> > > > project to take sensor readings and make them available over >> > > > dbus. I >> > > > feel that this takes away from the generic concept that >> everything >> > > > is >> > > > a file. >> > > > >> > > > Does this code perhaps have a better home in libinput? >> > > > >> > > > https://github.com/hadess/iio-sensor-proxy >> > > >> > > I don't think so. iio-sensor-proxy is not at the same level as >> > > libinput, and >> > > the dbus API is there for a reason. in theory, a libinput-based >> > > solution >> > > would be for libinput to read the sensors and have iio-sensor- >> proxy >> > > wrap >> > > libinput to provide the dbus API that applications require. >> > > >> > > That wouldn't add anything to the current solution though, it'd >> be >> > > mostly >> > > code churn for little benefit. so unless Bastian requests that we >> add >> > > this >> > > to libinput, I don't think this is worth pursuing. >> > >> > It's at the wrong level (it needs to be system unique, as IIO >> doesn't >> > support concurrent uses), and having a single daemon allows us to >> share >> > code to support the other sensor types. >> It should be far more beneficial to add support to iio, then it is to >> write a single purpose daemon that fails to fix the cause while >> addressing only the symptoms. > > Be my guest. The ABI of the IIO subsystem in the Linux kernel won't be > changed. -- 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
