User-space API for accelerometer(s)?
Hey,
I'm trying to integrate the accelerometer of the Lenovo Yoga into GNOME and a modern desktop. The accelerometer is exported through an IIO device as per:
https://github.com/pfps/yoga-laptop/blob/master/sensors/orientation.c
We already have some integration for accelerometers in udev/systemd and GNOME, and they rely on the accelerometer being an input device, being tagged with the ID_INPUT_ACCELEROMETER and sending out a kevent/uevent when a major orientation change took place. This is handled by:
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/accelerometer/accelerometer.c
for the WeTab/Pegatron devices for example.
So, my question regarding the IIO user-space API is:
is it possible to make the IIO accelerometer send out a kevent when the orientation changes in a major way (using triggers?) or does user-space need to poll the device instead?
If the former, I intend on writing a small helper to set up the accelerometer, and a helper similar to the one already in the udev tree.
If the latter, I'll probably write a long-running helper, which would offer the same interface as the one used by the Pegatron accelerometer driver, so that we don't need to make any more changes to user-space.
Cheers
Hello Bastien Nocera,
I'm not the best person to answer your questions but I will try and help. The best people to talk to would be Jonathan Cameron, the IIO maintainer, and Srinivas Pandruvada, the author of the hid-sensor-hub device drivers. I have CC'ed them for you to hopefully get a better response than what I can offer.
Your device uses the same sensor hub, over usb, as my device does. I have a Microsoft Surface and it also uses many of the sensors found on the Lenovo Yoga.
Quoted 4 lines
So, my question regarding the IIO user-space API is:
is it possible to make the IIO accelerometer send out a kevent when the orientation changes in a major way (using triggers?) or does user-space need to poll the device instead?
Of course it's possible but this does not occur in the current hid sensor hub drivers, from my understanding of the code. You should probably check out the current documentation on the IIO sysfs user interface:
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio
These outline the possible attributes sysfs offers. As of now the only ones that are found on the hid sensor hub devices is _raw as of 3.16 and _scale, _offset, _sampling_frequency, _hysteresis. The raw attribute lets you read the data that is at the top of the iio buffer. As you can see in the documentation there are many events support by other drivers that could possible be implemented by the hid-sensor-hub devices.
IIO devices use a buffer that have a fixed size. It can be enabled with the sysfs interface. An example of this can be found in the kernel (drivers/staging/iio/iio_simple_dummy_buffer.c) there is also additional documentation there as well as dummy drivers.
To use these interfaces in user space, or in the context of GNOME desktop, I think you would need to poll the iio buffer for new data and calculate the changes that way. The iio subsystem does support events but you would need to add these to the hid-sensor-hub devices and do the calculations for each event. This would allow you to poll for these iio events instead of polling the buffer.
Hope this helps,
Reyad Attiyat
Quoted 8 lines · Reyad Attiyat
Hello Bastien Nocera,
I'm not the best person to answer your questions but I will try and help. The best people to talk to would be Jonathan Cameron, the IIO maintainer, and Srinivas Pandruvada, the author of the hid-sensor-hub device drivers. I have CC'ed them for you to hopefully get a better response than what I can offer.
Quoted 8 lines
Your device uses the same sensor hub, over usb, as my device does. I have a Microsoft Surface and it also uses many of the sensors found on the Lenovo Yoga.
Quoted 4 lines
So, my question regarding the IIO user-space API is:
is it possible to make the IIO accelerometer send out a kevent when the orientation changes in a major way (using triggers?) or does user-space need to poll the device instead?
You can check a program called generic_buffer.c in "drivers/staging/iio/Documentation". I have used this as a reference to port to Android. You don't need to poll, you can also check "https://github.com/pfps/yoga-laptop/sensors " developed by Peter F. Patel-Schneider.
Thanks,
Srinivas
Quoted 30 lines
Of course it's possible but this does not occur in the current hid sensor hub drivers, from my understanding of the code. You should probably check out the current documentation on the IIO sysfs user interface:
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iioThese outline the possible attributes sysfs offers. As of now the only ones that are found on the hid sensor hub devices is
_rawas of 3.16 and_scale,_offset,_sampling_frequency,_hysteresis. The raw attribute lets you read the data that is at the top of the iio buffer. As you can see in the documentation there are many events support by other drivers that could possible be implemented by the hid-sensor-hub devices.IIO devices use a buffer that have a fixed size. It can be enabled with the sysfs interface. An example of this can be found in the kernel (
drivers/staging/iio/iio_simple_dummy_buffer.c) there is also additional documentation there as well as dummy drivers.To use these interfaces in user space, or in the context of GNOME desktop, I think you would need to poll the iio buffer for new data and calculate the changes that way. The iio subsystem does support events but you would need to add these to the hid-sensor-hub devices and do the calculations for each event. This would allow you to poll for these iio events instead of polling the buffer.
Hope this helps,
Reyad Attiyat
Quoted 18 lines · Srinivas Pandruvada
Quoted 8 lines · Reyad Attiyat
Hello Bastien Nocera,
I'm not the best person to answer your questions but I will try and help. The best people to talk to would be Jonathan Cameron, the IIO maintainer, and Srinivas Pandruvada, the author of the hid-sensor-hub device drivers. I have CC'ed them for you to hopefully get a better response than what I can offer.
Quoted 8 lines
Your device uses the same sensor hub, over usb, as my device does. I have a Microsoft Surface and it also uses many of the sensors found on the Lenovo Yoga.
Quoted 4 lines
So, my question regarding the IIO user-space API is:
is it possible to make the IIO accelerometer send out a kevent when the orientation changes in a major way (using triggers?) or does user-space need to poll the device instead?
Quoted 6 lines
You can check a program called
generic_buffer.cin "drivers/staging/iio/Documentation". I have used this as a reference to port to Android.
You don't need to poll, you can also check "https://github.com/pfps/yoga-laptop/sensors " developed by Peter F. Patel-Schneider.
I've read this code, and in fact, I mentioned it in my original mail. I fail to see how this code isn't polling. It's also much more complicated than doing the same thing for a evdev accelerometer.
Jonathan Cameron
maintainerQuoted 26 lines · Bastien Nocera
Quoted 18 lines · Srinivas Pandruvada
Quoted 8 lines · Reyad Attiyat
Hello Bastien Nocera,
I'm not the best person to answer your questions but I will try and help. The best people to talk to would be Jonathan Cameron, the IIO maintainer, and Srinivas Pandruvada, the author of the hid-sensor-hub device drivers. I have CC'ed them for you to hopefully get a better response than what I can offer.
Quoted 8 lines
Your device uses the same sensor hub, over usb, as my device does. I have a Microsoft Surface and it also uses many of the sensors found on the Lenovo Yoga.
Quoted 4 lines
So, my question regarding the IIO user-space API is:
is it possible to make the IIO accelerometer send out a kevent when the orientation changes in a major way (using triggers?) or does user-space need to poll the device instead?Quoted 6 lines
You can check a program called
generic_buffer.cin "drivers/staging/iio/Documentation". I have used this as a reference to port to Android.
You don't need to poll, you can also check "https://github.com/pfps/yoga-laptop/sensors " developed by Peter F. Patel-Schneider.
Quoted 4 lines
I've read this code, and in fact, I mentioned it in my original mail. I fail to see how this code isn't polling. It's also much more complicated than doing the same thing for a evdev accelerometer.
Just to throw it in there. There is an out of tree bridge driver from IIO to input. It's only out of tree because I haven't had a chance to tidy it up (anyone else is welcome to take this on if they like!) Google for iio_input.c to find it.
The intent of that was to allow general accelerometer drivers and similar in IIO to work in conjunction with iio-input to provide input style interfaces. This came about after previous debates on where the 'right' place for accelerometers was in the kernel. I believe that at least in principle, Dmitry was happy with this concept.
Jonathan
Quoted 27 lines · Jonathan Cameron
Quoted 26 lines · Bastien Nocera
Quoted 24 lines · Srinivas Pandruvada
Quoted 8 lines · Reyad Attiyat
Hello Bastien Nocera,
I'm not the best person to answer your questions but I will try and help. The best people to talk to would be Jonathan Cameron, the IIO maintainer, and Srinivas Pandruvada, the author of the hid-sensor-hub device drivers. I have CC'ed them for you to hopefully get a better response than what I can offer.
Quoted 8 lines
Your device uses the same sensor hub, over usb, as my device does. I have a Microsoft Surface and it also uses many of the sensors found on the Lenovo Yoga.
Quoted 4 lines
So, my question regarding the IIO user-space API is:
is it possible to make the IIO accelerometer send out a kevent when the orientation changes in a major way (using triggers?) or does user-space need to poll the device instead?You can check a program called
generic_buffer.cin "drivers/staging/iio/Documentation". I have used this as a reference to port to Android.
You don't need to poll, you can also check "https://github.com/pfps/yoga-laptop/sensors " developed by Peter F. Patel-Schneider.
Quoted 8 lines
Quoted 4 lines
I've read this code, and in fact, I mentioned it in my original mail. I fail to see how this code isn't polling. It's also much more complicated than doing the same thing for a evdev accelerometer.
Just to throw it in there. There is an out of tree bridge driver from IIO to input. It's only out of tree because I haven't had a chance to tidy it up (anyone else is welcome to take this on if they like!) Google for
iio_input.cto find it.
Found it, thanks :)
http://thread.gmane.org/gmane.linux.kernel.iio/4464/
(By the way, "iio_input", not "iio_snoop")
Quoted 5 lines
The intent of that was to allow general accelerometer drivers and similar in IIO to work in conjunction with iio-input to provide input style interfaces. This came about after previous debates on where the 'right' place for accelerometers was in the kernel. I believe that at least in principle, Dmitry was happy with this concept.
Cool. The only question left would be whether this could throw a kevent when the orientation changes in a major way. This is a firmware feature in the WeTab/Pegatron machine, and is useful because it avoids the need to have the accelerometer constantly opened when not needed (saving battery by avoiding wakeups).
Would it be worth adding such a feature inside the iio-input driver? I would have preferred it if the hardware sent those events, but I'd be happy just the same if the driver did it. The backing IIO device is always opened and processing data, it seems, whether or not the backing input device is opened in user-space or not.
Cheers
Quoted 45 lines · Bastien Nocera
Quoted 25 lines · Jonathan Cameron
Quoted 24 lines · Bastien Nocera
Quoted 23 lines · Srinivas Pandruvada
Quoted 8 lines · Reyad Attiyat
Hello Bastien Nocera,
I'm not the best person to answer your questions but I will try and help. The best people to talk to would be Jonathan Cameron, the IIO maintainer, and Srinivas Pandruvada, the author of the hid-sensor-hub device drivers. I have CC'ed them for you to hopefully get a better response than what I can offer.
Quoted 8 lines
Your device uses the same sensor hub, over usb, as my device does. I have a Microsoft Surface and it also uses many of the sensors found on the Lenovo Yoga.
Quoted 4 lines
So, my question regarding the IIO user-space API is:
is it possible to make the IIO accelerometer send out a kevent when the orientation changes in a major way (using triggers?) or does user-space need to poll the device instead?You can check a program called
generic_buffer.cin "drivers/staging/iio/Documentation". I have used this as a reference to port to Android.
You don't need to poll, you can also check "https://github.com/pfps/yoga-laptop/sensors " developed by Peter F. Patel-Schneider.Quoted 8 lines
Quoted 4 lines
I've read this code, and in fact, I mentioned it in my original mail. I fail to see how this code isn't polling. It's also much more complicated than doing the same thing for a evdev accelerometer.
Just to throw it in there. There is an out of tree bridge driver from IIO to input. It's only out of tree because I haven't had a chance to tidy it up (anyone else is welcome to take this on if they like!) Google for
iio_input.cto find it.Found it, thanks :)
http://thread.gmane.org/gmane.linux.kernel.iio/4464/
(By the way, "
iio_input", not "iio_snoop")Quoted 5 lines
The intent of that was to allow general accelerometer drivers and similar in IIO to work in conjunction with iio-input to provide input style interfaces. This came about after previous debates on where the 'right' place for accelerometers was in the kernel. I believe that at least in principle, Dmitry was happy with this concept.
Quoted 5 lines
Cool. The only question left would be whether this could throw a kevent when the orientation changes in a major way. This is a firmware feature in the WeTab/Pegatron machine, and is useful because it avoids the need to have the accelerometer constantly opened when not needed (saving battery by avoiding wakeups).
That will happen with sensor hubs, You can set the hysteresis to not to get awakened unless the change is significant.
Thanks,
Srinivas
Quoted 9 lines
Would it be worth adding such a feature inside the iio-input driver? I would have preferred it if the hardware sent those events, but I'd be happy just the same if the driver did it. The backing IIO device is always opened and processing data, it seems, whether or not the backing input device is opened in user-space or not.
Cheers
Hey again Jonathan,
On Sat, 2014-06-21 at 13:01 +0100, Jonathan Cameron wrote:
<snip>
Quoted 10 lines
Just to throw it in there. There is an out of tree bridge driver from IIO to input. It's only out of tree because I haven't had a chance to tidy it up (anyone else is welcome to take this on if they like!) Google for
iio_input.cto find it.The intent of that was to allow general accelerometer drivers and similar in IIO to work in conjunction with iio-input to provide input style interfaces. This came about after previous debates on where the 'right' place for accelerometers was in the kernel. I believe that at least in principle, Dmitry was happy with this concept.
After updating forward-porting the driver so that it runs on a more recent version of the kernel, I tried to get it running.
I'm guessing that you expected the iio_input driver to be instantiated by a board specific file. Is there any way to have it generically try out all the IIO devices, similarly to pci_register_driver()? Or should I do that in the hid-sensor-accel driver?
Cheers
Quoted 15 lines · Bastien Nocera
Hey again Jonathan,
On Sat, 2014-06-21 at 13:01 +0100, Jonathan Cameron wrote:
<snip>Quoted 10 lines
Just to throw it in there. There is an out of tree bridge driver from IIO to input. It's only out of tree because I haven't had a chance to tidy it up (anyone else is welcome to take this on if they like!) Google for
iio_input.cto find it.The intent of that was to allow general accelerometer drivers and similar in IIO to work in conjunction with iio-input to provide input style interfaces. This came about after previous debates on where the 'right' place for accelerometers was in the kernel. I believe that at least in principle, Dmitry was happy with this concept.
Quoted 7 lines
After updating forward-porting the driver so that it runs on a more recent version of the kernel, I tried to get it running.
I'm guessing that you expected the
iio_inputdriver to be instantiated by a board specific file. Is there any way to have it generically try out all the IIO devices, similarly topci_register_driver()? Or should I do that in the hid-sensor-accel driver?
At the moment we only have support to instantiate it via such a board specific file. We probably want to be a little careful about how to add more generic means for creating such bindings..
Simply generically trying all IIO drivers isn't the way to go as there is no obvious way of deciding what it makes sense to bind to on a given machine.
Perhaps something closer to the way you can instantiate i2c devices from userspace, or perhaps we need to consider something else such as configfs for creating such bindings... (cc'd Lars for comments on whether that makes sense...)
We did also have a uinput based approach at one point but it was fairly clunky. That took data from iio buffers and pushed it back into the kernel via inputs userspace driver support. Not particularly nice but I thought I'd best mention it!
J
Quoted 2 lines
Cheers
Quoted 27 lines · Jonathan Cameron
Quoted 15 lines · Bastien Nocera
Hey again Jonathan,
On Sat, 2014-06-21 at 13:01 +0100, Jonathan Cameron wrote:
<snip>Quoted 10 lines
Just to throw it in there. There is an out of tree bridge driver from IIO to input. It's only out of tree because I haven't had a chance to tidy it up (anyone else is welcome to take this on if they like!) Google for
iio_input.cto find it.The intent of that was to allow general accelerometer drivers and similar in IIO to work in conjunction with iio-input to provide input style interfaces. This came about after previous debates on where the 'right' place for accelerometers was in the kernel. I believe that at least in principle, Dmitry was happy with this concept.
Quoted 7 lines
After updating forward-porting the driver so that it runs on a more recent version of the kernel, I tried to get it running.
I'm guessing that you expected the
iio_inputdriver to be instantiated by a board specific file. Is there any way to have it generically try out all the IIO devices, similarly topci_register_driver()? Or should I do that in the hid-sensor-accel driver?At the moment we only have support to instantiate it via such a board specific file. We probably want to be a little careful about how to add more generic means for creating such bindings..
Quoted 6 lines
Simply generically trying all IIO drivers isn't the way to go as there is no obvious way of deciding what it makes sense to bind to on a given machine.
Perhaps something closer to the way you can instantiate i2c devices from userspace, or perhaps we need to consider something else such as configfs for creating such bindings... (cc'd Lars for comments on whether that makes sense...)
Yes, configfs is what came to my mind after reading the first few lines of Bastien's mail. Exposing a IIO device as something other than a IIO device is a policy decision. And policy decisions should preferably be made by userspace. But yea, we have to be careful with the ABI.
- Lars
Quoted 27 lines · Jonathan Cameron
Quoted 15 lines · Bastien Nocera
Hey again Jonathan,
On Sat, 2014-06-21 at 13:01 +0100, Jonathan Cameron wrote:
<snip>Quoted 10 lines
Just to throw it in there. There is an out of tree bridge driver from IIO to input. It's only out of tree because I haven't had a chance to tidy it up (anyone else is welcome to take this on if they like!) Google for
iio_input.cto find it.The intent of that was to allow general accelerometer drivers and similar in IIO to work in conjunction with iio-input to provide input style interfaces. This came about after previous debates on where the 'right' place for accelerometers was in the kernel. I believe that at least in principle, Dmitry was happy with this concept.
Quoted 7 lines
After updating forward-porting the driver so that it runs on a more recent version of the kernel, I tried to get it running.
I'm guessing that you expected the
iio_inputdriver to be instantiated by a board specific file. Is there any way to have it generically try out all the IIO devices, similarly topci_register_driver()? Or should I do that in the hid-sensor-accel driver?At the moment we only have support to instantiate it via such a board specific file. We probably want to be a little careful about how to add more generic means for creating such bindings..
Quoted 6 lines
Simply generically trying all IIO drivers isn't the way to go as there is no obvious way of deciding what it makes sense to bind to on a given machine.
Perhaps something closer to the way you can instantiate i2c devices from userspace, or perhaps we need to consider something else such as configfs for creating such bindings... (cc'd Lars for comments on whether that makes sense...)
Are there cases where we have a hid-sensor that we wouldn't want to expose through the input layer?
Quoted 4 lines
We did also have a uinput based approach at one point but it was fairly clunky. That took data from iio buffers and pushed it back into the kernel via inputs userspace driver support. Not particularly nice but I thought I'd best mention it!
That's actually something that I looked at and discussed with Benjamin. And it currently looks like the best possible solution in the short-term (I will only have the machine for a couple more weeks...).
Cheers
On Thu, 2014-07-03 at 18:51 +0100, Jonathan Cameron wrote:
<snip>
Quoted 4 lines
We did also have a uinput based approach at one point but it was fairly clunky. That took data from iio buffers and pushed it back into the kernel via inputs userspace driver support. Not particularly nice but I thought I'd best mention it!
This is how I went in the end:
https://github.com/hadess/iio-sensor-proxy/
It's still far too resource hungry compared to the amount of work it's doing (1 full percent of CPU!), and the rotation is too sensitive.
But, along with this systemd patch:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=a545c6e1aa31b4d7e80c9d3609d9fc4fc9921498
It works out of the box with GNOME's orientation plugin.
I think that the code could also do with a bit more cleanup.
Please drop me a mail privately or file an issue if you can test this on various systems (other models of Yoga and the Surface would be nice to test), and I'll add it to the list of tested devices.
Cheers
Hello Bastian,
Quoted 10 lines
Quoted 4 lines
We did also have a uinput based approach at one point but it was fairly clunky. That took data from iio buffers and pushed it back into the kernel via inputs userspace driver support. Not particularly nice but I thought I'd best mention it!
This is how I went in the end:
https://github.com/hadess/iio-sensor-proxy/It's still far too resource hungry compared to the amount of work it's doing (1 full percent of CPU!), and the rotation is too sensitive.
if I read the code correctly, prepare_output() configures the trigger, enables the buffer, then performs one read, before undoing everything FOR EACH SAMPLE
this is probably not the way it should be done; I'd suggest to set up the IIO buffer and then poll() or block on /dev/iio:deviceX -- however, this uses the IIO device exclusively (might be an issue)
regards, p.
Signature · 2 lines
Peter Meerwald +43-664-2444418 (mobile)
Hey Peter,
Quoted 10 lines · Peter Meerwald
Hello Bastian,
Quoted 8 lines
Quoted 4 lines
We did also have a uinput based approach at one point but it was fairly clunky. That took data from iio buffers and pushed it back into the kernel via inputs userspace driver support. Not particularly nice but I thought I'd best mention it!
This is how I went in the end:
https://github.com/hadess/iio-sensor-proxy/
Quoted 6 lines
Quoted 2 lines
It's still far too resource hungry compared to the amount of work it's doing (1 full percent of CPU!), and the rotation is too sensitive.
if I read the code correctly,
prepare_output()configures the trigger, enables the buffer, then performs one read, before undoing everything FOR EACH SAMPLE
I based that code off Peter F. Patel-Schneider, and his yoga utilities, and he probably got the idea from the generic_buffer.c example. It's not clear what needs to be done there.
Quoted 3 lines
this is probably not the way it should be done; I'd suggest to set up the IIO buffer and then
poll()or block on /dev/iio:deviceX -- however, this uses the IIO device exclusively (might be an issue)
I've now pushed a version that will do the setup once, and open/close the iio device when needed, in the timeout.
The daemon still shows up in top, but I couldn't make it register
enough activity to show up in sysprof, so I'm guessing that top just isn't measuring the CPU usage accurately.
I still have to fix the overeagerness to switch orientations, and I'll be done for now I think.
Cheers
Yes, my code derives from generic-buffer, at least in part, as I first had to fix problems in generic-buffer, and then get problems fixed in the sensor hub drivers. For quite some time the only way to get the code to work at all was to do everything each time, so I just kept doing it that way.
There appears to be lots of improvements in the drivers so a better solution is certainly possible now.
peter
Quoted 44 lines · Bastien Nocera
Hey Peter,
Quoted 10 lines · Peter Meerwald
Hello Bastian,
Quoted 8 lines
Quoted 4 lines
We did also have a uinput based approach at one point but it was fairly clunky. That took data from iio buffers and pushed it back into the kernel via inputs userspace driver support. Not particularly nice but I thought I'd best mention it!
This is how I went in the end:
https://github.com/hadess/iio-sensor-proxy/Quoted 6 lines
Quoted 2 lines
It's still far too resource hungry compared to the amount of work it's doing (1 full percent of CPU!), and the rotation is too sensitive.
if I read the code correctly,
prepare_output()configures the trigger, enables the buffer, then performs one read, before undoing everything FOR EACH SAMPLEI based that code off Peter F. Patel-Schneider, and his yoga utilities, and he probably got the idea from the
generic_buffer.cexample. It's not clear what needs to be done there.Quoted 3 lines
this is probably not the way it should be done; I'd suggest to set up the IIO buffer and then
poll()or block on /dev/iio:deviceX -- however, this uses the IIO device exclusively (might be an issue)I've now pushed a version that will do the setup once, and open/close the iio device when needed, in the timeout.
The daemon still shows up in top, but I couldn't make it register
enough activity to show up in sysprof, so I'm guessing that top just isn't measuring the CPU usage accurately.I still have to fix the overeagerness to switch orientations, and I'll be done for now I think.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I suggest to look at https://01.org/android-ia/downloads. Under device/intel, you can see user space HAL for sensor hubs.
Thanks,
Srinivas
Quoted 63 lines · Peter F. Patel-Schneider
Yes, my code derives from generic-buffer, at least in part, as I first had to fix problems in generic-buffer, and then get problems fixed in the sensor hub drivers. For quite some time the only way to get the code to work at all was to do everything each time, so I just kept doing it that way.
There appears to be lots of improvements in the drivers so a better solution is certainly possible now.
peter
Quoted 49 lines · Bastien Nocera
Hey Peter,
Quoted 13 lines · Peter Meerwald
Hello Bastian,
Quoted 11 lines
Quoted 7 lines
We did also have a uinput based approach at one point but it was fairly clunky.
That took data from iio buffers and pushed it back into the kernel via inputs
userspace driver support. Not particularly nice but I thought I'd best mention
it!This is how I went in the end:
https://github.com/hadess/iio-sensor-proxy/Quoted 7 lines
Quoted 2 lines
It's still far too resource hungry compared to the amount of work it's doing (1 full percent of CPU!), and the rotation is too sensitive.
if I read the code correctly,
prepare_output()configures the trigger, enables the buffer, then performs one read, before undoing everything FOR
EACH SAMPLEI based that code off Peter F. Patel-Schneider, and his yoga utilities, and he probably got the idea from the
generic_buffer.cexample. It's not clear what needs to be done there.Quoted 4 lines
this is probably not the way it should be done; I'd suggest to set up the
IIO buffer and thenpoll()or block on /dev/iio:deviceX -- however, this uses the IIO device exclusively (might be an issue)I've now pushed a version that will do the setup once, and open/close the iio device when needed, in the timeout.
The daemon still shows up in top, but I couldn't make it register
enough activity to show up in sysprof, so I'm guessing that top just isn't measuring the CPU usage accurately.I still have to fix the overeagerness to switch orientations, and I'll be done for now I think.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Srinivas Pandruvada
I suggest to look at https://01.org/android-ia/downloads. Under device/intel, you can see user space HAL for sensor hubs.
I can't find it anywhere on those pages. There only seems to be installable images, with no source code.
Quoted 6 lines · Bastien Nocera
Quoted 2 lines · Srinivas Pandruvada
I suggest to look at https://01.org/android-ia/downloads. Under device/intel, you can see user space HAL for sensor hubs.
I can't find it anywhere on those pages. There only seems to be installable images, with no source code.
You can see instruction here to get source code. You can see source in device/intel folder.
https://01.org/android-ia/downloads/android-4.4.2r1-ia1
Thanks,
Srinivas
Quoted 4 lines · Srinivas Pandruvada
Quoted 3 lines · Bastien Nocera
Quoted 2 lines · Srinivas Pandruvada
I suggest to look at https://01.org/android-ia/downloads. Under device/intel, you can see user space HAL for sensor hubs.
Quoted 8 lines
Quoted 3 lines
I can't find it anywhere on those pages. There only seems to be installable images, with no source code.
You can see instruction here to get source code. You can see source in device/intel folder.
Right, I found this:
https://github.com/android-ia/device_intel/blob/release/android-4.1.1_r1-ia0/pc_std/libsensors/SensorConfig.h
Which seems to have a number of bugs (defines "GRAVITY" but actually uses "GRAVITY_EARTH" in some of the formulas), and doesn't make it clear which one of the sensors each of the sections are for.
In any case, my problem was simply one of threshold. For reference, I've also downloaded Microsoft's documentation for hardware manufacturers:
http://msdn.microsoft.com/en-us/library/windows/hardware/dn613934(v=vs.85).aspx
Cheers