[Feature request]: Support any iio light sensor

[justinlovinger]

Please describe your feature request

I have two devices with iio light sensors not in the hardcoded list at https://github.com/max-baz/wluma/blob/main/src/als/iio.rs#L39. Wluma fails with No iio device found, even though they have iio device light sensors. As far as I can tell, if the filter_map at https://github.com/max-baz/wluma/blob/main/src/als/iio.rs#L39 was removed, Wluma would work, and I don't understand why that check is even there. Shouldn't checking if the device provides illuminance data be enough? That's what the next filter_map does, the one at https://github.com/max-baz/wluma/blob/main/src/als/iio.rs#L50.

For reference, the devices are a PinePhone Pro with an stk3310 iio light sensor and a Steam Deck with a ltrf216a iio light sensor.

[max-baz]

Why that check is even there is a combination of:

• Early on I didn't expect there to be a zoo of als sensors 😅
• As we first find what claims to be a sensor by its name, we can loudly fail if we can't parse it - a more explicit guarantee
• So far when we had to expand that hardcoded list, we often also had to actually implement the parser for it - the app didn't come from day one with support for all those different parsers we have today.

It doesn't have to stay this way, I'd be okay to drop the name filter! Can you actually confirm though that if you remove that filter_map block, that wluma is actually able to use both sensors?

[justinlovinger]

I patched out the name check, and Wluma now works with my IIO sensors. Patch below:

diff --git a/src/als/iio.rs b/src/als/iio.rs
index 865bca9..996ac81 100644
--- a/src/als/iio.rs
+++ b/src/als/iio.rs
@@ -33,20 +33,6 @@ impl Als {
             .await
             .map_err(|e| anyhow!("Can't enumerate iio devices: {e}"))?
             .filter_map(|r| async { r.ok() })
-            .then(|entry| {
-                smol::fs::read_to_string(entry.path().join("name")).map(|name| (name, entry))
-            })
-            .filter_map(|(name, entry)| async {
-                [
-                    "als",
-                    "acpi-als",
-                    "apds9960",
-                    "cros-ec-light",
-                    "aop-sensors-als",
-                ]
-                .contains(&name.unwrap_or_default().trim())
-                .then_some(entry)
-            })
             .filter_map(|entry| async move {
                 // TODO should probably start from the `parse_illuminance_input` in the next major version
                 parse_illuminance_raw(entry.path())

Note, the log::error!("Failed to read sensor '{}'", entry.path().display()); line should probably also be removed, as it can now trigger as a false negative.

Looking at the code, I think it makes more sense to just check if the light data can be parsed, instead of checking the name of the sensor. There are far fewer ways to provide light data than there are sensors themselves. For example, I noticed the last feature addition was just adding a line to the hardcoded list, https://github.com/max-baz/wluma/pull/162/changes.

P.S. Wluma core dumps on my PinePhone Pro, but that occurs after successfully detecting the IIO sensor, and I suspect the issue is related to the device being ARM, not the above patch.

[justinlovinger]

Looking at the code further, the core dump was almost certainly related to the unsafe Vulkan code, as the PinePhone Pro does not support Vulkan. Setting capturer to none fixed it.