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
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