As we don't return when the file doesn't exist, don't print a warning
either, as this would pollute logs and throw people off when debugging
real problems.
Closes: #180
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
Using 4.8-rc kernel, orientation got flipped. The right-up became normal
and normal became right-up. The reason for this is that orientation code
of iio-sensor-proxy observes x and y swapped (actually they are not in
the data provided by IIO).
Although it is triggered by some kernel change, the reliance on
g_dir_read_name() to get the correct order of channels is not correct.
We should look at the in_xxx_x_index field and calculate correct byte
offset in the iio buffer data.
For example with 4.8 kernel: from log with added index location printed
** (process:4945): DEBUG: Built channel array for in_accel_y: index: 1, is signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:4945): DEBUG: Built channel array for in_accel_x: index: 0, is signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:4945): DEBUG: Built channel array for in_accel_z: index: 2, is signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
(Here in_accel_y appeared before in_accel_x in g_dir_read_name(), because
of that channel array ordering is wrong hence location was
calculated wrong as below)
...
...
** (process:4945): DEBUG: process_scan_1: channel_index: 1, chan_name: in_accel_x, channel_data_index: 0 location: 4
** (process:4945): DEBUG: process_scan_1: channel_index: 0, chan_name: in_accel_y, channel_data_index: 1 location: 0
** (process:4945): DEBUG: process_scan_1: channel_index: 2, chan_name: in_accel_z, channel_data_index: 2 location: 8
** (process:4945): DEBUG: Read from IIO: -880449, 32851, -457812
To fix this we need to calculate the byte offset location using
channel_index not in the order they are returned by g_dir_read_name().
The easiest fix is to sort the array of channels in
build_channel_array() based on index. Also added some debug to print
index and location.
After the fix, the above log will change to:
** (process:4674): DEBUG: Built channel array for in_accel_x: index: 0, is signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:4674): DEBUG: Built channel array for in_accel_y: index: 1, is signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:4674): DEBUG: Built channel array for in_accel_z: index: 2, is signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
(Sorted above, so location of byte offset is correct)
** (process:4674): DEBUG: process_scan_1: channel_index: 0, chan_name: in_accel_x, channel_data_index: 0 location: 0
** (process:4674): DEBUG: process_scan_1: channel_index: 1, chan_name: in_accel_y, channel_data_index: 1 location: 4
** (process:4674): DEBUG: process_scan_1: channel_index: 2, chan_name: in_accel_z, channel_data_index: 2 location: 8
** (process:4674): DEBUG: Read from IIO: 34804, -878496, -448046
Closes: #99
Add a scale output parameter in process_scan_1 so that we pass scale
information from each driver read to the driver, and apply the scale
before passing it on to the main daemon.
Closes#28
In most IIO sensor types, _scale and _offset is added to the scan element base
name, for example:
in_accel has in_accel_scale and in_accel_offset
For compasses, this is different. Instead of being named
in_rot_from_north_magnetic_tilt_scale aand similar, the _scale and_offset
attributes are named in_rot_scale and in_rot_offset.
This commit adds a workaround to special-case the attribute naming for this
type of sensor.
