Rather than attach to a Lid Switch that's only available on laptops,
attach it to the power button, which we're much more likely to find on
any machine.
This also fixes the logic of the conditional which would exit when it
found a lid switch...
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.
gcc8 does not like it when casting from a function with no arguments to one
which actually expects arguments, causing it to throw errors like these:
drv-fake-compass.c: In function ‘first_values’:
drv-fake-compass.c:66:51: error: cast between incompatible function types from ‘gboolean (*)(void)’ {aka ‘int (*)(void)’} to ‘gboolean (*)(void *)’ {aka ‘int (*)(void *)’} [-Werror=cast-function-type]
drv_data->timeout_id = g_timeout_add_seconds (1, (GSourceFunc) compass_changed, NULL);
^
This fixes this.
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
Disable PrivateNetwork lockdown so we can get access to uevents that
tell us whether sensors got removed or added, but allow enough
networking for udev to work correctly.
Fixes the regression introduced in 45f9a638.
We used to look for sensor devices at the same time as we were setting
up D-Bus. If D-Bus was ready when we finished probing for devices, then
we'd send a D-Bus event. But we would also try to send a D-Bus event
when we got our first event from the sensors, at which point D-Bus might
not be ready.
We really shouldn't be trying to probe and setup the sensors before we
know we can own the D-Bus name, as that might mean that another service
is already running, and we might just break the existing daemon.
Closes#147
systemd 232 does not include the necessary rules to apply the quirks to
accelerometers. This requires this commit:
1f886b50f6
which can easily be backported to earlier systemd versions as
appropriate.
See https://github.com/systemd/systemd/pull/5280
D-Bus policy XML files are generic configuration for the bus daemon:
they are conventionally named like a bus name, but there is nothing
that inherently limits their application to that bus name.
In particular this means that a rule like
<policy context="default">
<allow send_interface="org.freedesktop.DBus.Properties"/>
allows any process on the system bus to send an
org.freedesktop.DBus.Properties.Set() call to any other process on the
system bus, even if the destination process expected to be only
accessible by root.
Closes: #41
Instead of using the real "Lid Switch" device to attach our fake compass
to, use "Power Button". "Lid Switch" will only be present on laptops,
but "Power Button" is in both laptops and desktops, making it easier to
test.
In commit 924dd58, we changed from matching the device names to a more
generic property match. But we matched on the "iio-buffer-compass"
property instead of the one actually set in the udev rules
("iio-compass").
Change the udev rules property name to "iio-buffer-compass" so that
rules and code match.
This fixes iio-sensor-proxy startup on HP Pavilion x360.
Spotted by Ted Ying <yingted@gmail.com>
Closes: #128
