On error, the channel info would just be left unfreed.
From Coverity:
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:330: leaked_storage: Variable "current" going out of scope leaks the storage it points to.
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:312: leaked_storage: Variable "current" going out of scope leaks the storage it points to.
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:304: leaked_storage: Variable "current" going out of scope leaks the storage it points to.
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:302: leaked_storage: Variable "current" going out of scope leaks the storage it points to.
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:293: leaked_storage: Variable "current" going out of scope leaks the storage it points to.
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:289: leaked_storage: Variable "current" going out of scope leaks the storage it points to.
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:350:2: warning[unix.Malloc]: Potential leak of memory pointed to by 'current'
From Coverity:
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:769: noescape: Resource "buffer_data" is not freed or pointed-to in "buffer_drv_data_free".
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:770:3: warning[unix.Malloc]: Potential leak of memory pointed to by 'buffer_data'
From Coverity:
iio-sensor-proxy-3.3/src/iio-buffer-utils.c:111: overwrite_var: Overwriting "filename" in "filename = g_build_filename(device_dir, "scan_elements", builtname, NULL)" leaks the storage that "filename" points to.
Reimplement iioutils_get_param_float() to parse float data like it would
in the C locale. This fixes the scale being '0' for every axis on some
systems and in some locales.
This is used to get the scale and offset parameters from buffer IIO drivers.
Fixes: 9f49caaf17Closes: #331
On some machines, iio-sensor-proxy was returning all 0's for IIO sensor
values. It turns out that the bits_used for this sensor is 32, which makes
the mask calculation:
*mask = (1 << 32) - 1;
If the compiler interprets the 1 literals as 32-bit ints, it generates
undefined behavior depending on compiler version and optimization level.
On my system, it optimizes out the shift, so the mask value becomes
*mask = (1) - 1;
With a mask value of 0, iio-sensor-proxy will always return 0 for every axis.
Avoid incorrect 0 values caused by compiler optimization.
Closes: #270
The scale should always be set to 1.0 by default, and only ever be
overridden if we could successfully read it from sysfs, and ch_present
is obviously false until we've found the channel in question.
Check whether we managed to open the index file instead of crashing.
#0 0x00007f31843660c7 in __vfscanf_internal () at /lib64/libc.so.6
#1 0x00007f31843657ed in __isoc99_fscanf () at /lib64/libc.so.6
#2 0x0000560bfd6b942b in build_channel_array (counter=0x560bfdea01c8, device_dir=0x560bfde90810 "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:273F:1008.0044/HID-SENSOR-200041.2.auto/iio:device0")
at iio-buffer-utils.c:320
#3 0x0000560bfd6b942b in build_channels (data=0x560bfdea01b0) at iio-buffer-utils.c:739
(gdb) frame 2
#2 0x0000560bfd6b942b in build_channel_array (counter=0x560bfdea01c8, device_dir=0x560bfde90810 "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:273F:1008.0044/HID-SENSOR-200041.2.auto/iio:device0")
at iio-buffer-utils.c:320
320 fscanf (sysfsfp, "%u", ¤t->index);
(gdb) p sysfsfp
$1 = (FILE *) 0x0
Add a new iio_fixup_sampling_frequency() helper to iio-buffer-utils.c and
call this for all iio devices. iio_fixup_sampling_frequency() makes sure that
devices with *sampling_frequency attributes are sampling at 10Hz or more.
This fixes 2 problems:
1) Some buffered devices default their sampling_frequency to 0Hz and then
never produce any readings. This fixes e.g. the sensors on Asus T100HA
2-in-1s not working.
2) Some polled devices default to 1Hz and wait for a fresh sample before
returning from sysfs *_raw reads, blocking all of iio-sensor-proxy for
multiple seconds, this fixes e.g. rotation being detected up to 10 seconds
later then the actual rotating of the device on a Lenovo Miix 320.
0640bf0 added helpers to fetch unaligned memory, but didn't take
the offset to the data location into account, reading from
the header instead.
Closes: #195
iio-buffer-utils.c: In function 'process_scan_1':
iio-buffer-utils.c:495:20: error: cast increases required alignment of target type [-Werror=cast-align]
guint32 val = *(guint32 *) (data + buffer_data->channels[k]->location);
^
iio-buffer-utils.c:501:19: error: cast increases required alignment of target type [-Werror=cast-align]
gint32 val = *(gint32 *) (data + buffer_data->channels[k]->location);
^
Looks like there's no need to cast.
Closes: #113
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
