That would be used in the cm36651 kernel driver, as well as devices with
multiple channels, such as combined proximity and light sensors, which use
"illuminance_clear" as the channel name.
Allows detection of RGBC sensing devices such as the apds9960 by checking for
the in_intensity_clear_ property, which reports the unprocessed lux value for the ALS photodiode.
More information on the field can be found in the kernel iio docs:
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio.
Tested on a MSHW1084, which is compatible with te apds9960. The apsd9960
reference can be found here: https://docs.broadcom.com/doc/AV02-4191EN.
Don't overwrite an already set type for light and ambient to support
multi channel sensors.
This reverts commit 5ef75b57a988a8a6acc2611cde760f28fc7b48d6.
That would be used in the tsl2772 and lm3533 kernel drivers, as well as
devices with multiple channels, such as combined proximity and light
sensors, which use "illuminance0" as the channel name instead of
"illuminance".
Closes: #290
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.
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
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
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).
40-* is too early to have some of the tags added to devices we want to
use. For example, input accelerometers wouldn't be tagged for
iio-sensor-proxy usage, as the tagging would be done in 50-*.
80 seems to be a good priority.
Closes#71
The daemon wasn't starting on, at least, MacBooks because the systemd
tag was missing, not starting the systemd iio-sensor-proxy.service unit.
Closes#25