Can you guess whether this was tested:
Accel read from IIO on '(null)': 0, 0, 0 (scale 1.0)
The NAME udev property was not available, so use the "name" sysfs
attribute instead, and don't use the readings struct before we've set
it.
Some IIO drivers have the ability to use triggers, but we'd fail at
runtime because no trigger was available for use. Fix that by checking
for a trigger being available early, and allow the poll driver to drive
buffer devices without a trigger.
Mount-matrix for devices that require them are now read from udev.
In some cases, the information is already available in the
device's firmware, but the kernel does not export it. Bear this
in mind when writing quirks.
This allow us to verify that the mount-matrix applied to accel
vectors give us the right orientation.
The vectors were captured on a Onda v975, without quirks applied.
For automated testing eventually.
The values were taken from the SensorInfo application for
Windows 10. For now, our tests will fail because of the
quirks we wrongfully applied.
One function to parse the mount matrix string in the format exported by
the iio core in Linux to a 3x3 matrix, and another to apply the mount
matrix to an existing 3-dimensional vector.
This means that the buffer driver can now handle more than the
bog-standard HID sensor hub, and that the polling driver can handle any
IIO polling device.
Closes: #39
For every type of device we support, tag the device with an
IIO_SENSOR_PROXY_TYPE property which the drivers can use to filter the
type of driver it will use.
This also means that hwmon temperature sensors, unsupported IIO sensors,
etc. don't start iio-sensor-proxy, and iio-sensor-proxy doesn't appear
in the udev output for that device (which lead to folks thinking their
hardware had light sensors or an accelerometer, which it didn't).
The IIO core, or the HID layer for HID sensor hubs, seems not
to like being poked straight after waking up, so add an
artificial delay during startup.
This is similar to the work-arounds doing the rounds in the
iio-sensor-proxy issues that switch the service type to idle
which would add a delay of up to 5 seconds by waiting for
other daemons to have finished startup.
This will need a real fix in the kernel at some point.
build_channel_array() goes through each directory member in
scan_elements folder and tries to get scale and offset of matching
elements. But there will be no scale and offset for some elements
like timestamp.
For example:
in_accel_x_en in_accel_y_en in_accel_z_en in_timestamp_en
in_accel_x_index in_accel_y_index in_accel_z_index in_timestamp_index
in_accel_x_type in_accel_y_type in_accel_z_type in_timestamp_type
When scale and offset not present, iioutils_get_param_float() will fail,
this causes return from the build_channel_array().
It shouldn't return when the error is caused by the attribute not being
present as, in this case, in_time_stamp_scale.
This was fixed in the kernel's iio_utils.c in commit 7868dfd.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7868dfd216074fc5f902e7befacda2a0ec76e403Closes: #114
As per the documentation of g_ptr_array_sort
"Note that the comparison function for g_ptr_array_sort() doesn't take the
pointers from the array as arguments, it takes pointers to the pointers in
the array"
So the arguments to the function
compare_channel_index (gconstpointer a, gconstpointer b)
needs to be dereferenced to get pointer to iio_channel_info.
The error was included in the fixup for commit 984803b by
the maintainer.
Closes#99
The original orientation code was based upon code that expected 1G to
roughly correspond to a reading of 256, to work-around the fact that the
input layer could not pass fractional values easily.
So the orientation_calc() code expected that too. But IIO readings after
scaling are properly in m/s², and our readings are integers.
We'll pass the scaling around to be applied at the last minute, when
doing calculations.
Closes: #100
