[Bug]: IIO value stuck at initial launch value

[wolf-yuan-6115]

Steps for reproducing the issue

1. Configure ALS IIO device

What is the buggy behavior?

After launching wluma with debug logging, I got following output:

[2026-02-02T14:10:02Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:03Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:03Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:03Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:03Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:03Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:04Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:04Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:04Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:04Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:04Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:05Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:05Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:05Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:05Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:05Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:06Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:06Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:06Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:06Z TRACE wluma::als::iio] ALS (iio): normal (270)
[2026-02-02T14:10:06Z TRACE wluma::als::iio] ALS (iio): normal (270)

I did cover the sensor with my hand during these time.

However cat /sys/bus/iio/devices/iio:device2/in_illuminance_raw will change based on current ambient brightness.

What is the expected behavior?

Not sure, perhaps value will change?

Logs

As above.

Version

4.10.0

Environment

- CachyOS
- hyprland 0.53.3

[max-baz]

Thanks for reporting, that's weird! Would you be able to debug a bit more? This log file seems to be really printing the value read from the file, I'm a bit puzzled as to why it can happen?

This is the file you could add a bunch of log lines to:

wluma/src/als/iio.rs

Line 68 in 34ea77c

log::trace!("ALS (iio): {} ({})", profile, raw);

[wolf-yuan-6115]

I got a surprise found. It seems like wluma is pulling the brightness value way too often. After changing WAITING_SLEEP_MS in als/controller.rs to around 500ms or so, the problem is solved.

Perhaps the driver doesn't like to be called this often?

[max-baz]

That's quite interesting! Can you confirm that while wluma is running with a high read frequency, wluma is stuck at seeing the same value (e.g. 270) while at the same time cat is able to read the real value in parallel? I find this most surprising, if this is the case, it makes me feel like maybe wluma is "losing" the real file pointer somehow...?

[wolf-yuan-6115]

That's quite interesting! Can you confirm that while wluma is running with a high read frequency, wluma is stuck at seeing the same value (e.g. 270) while at the same time cat is able to read the real value in parallel? I find this most surprising, if this is the case, it makes me feel like maybe wluma is "losing" the real file pointer somehow...?

Nope, if wluma is using 10Hz sampling rate, cat value is stuck when reading in parallel.

[max-baz]

Okay great, thanks! This is a surprisingly complicated topic to get right, I want to focus on it at some point, but I don't know yet when I'll have a chance. I hope you don't mind running a locally compiled wluma with the patch for the time being?

The big problem with just making this value configurable is that this can totally mess up the training data - with your value of 500 the chance is small, but I still want to get it right if we open this for general public. Right now, wluma has multiple parallel threads, one is watching als, another is watching brightness changes, another is watching screen contents, and yet another is trying to make the decisions based on all those factors. And the danger is that with a bad luck you can get into a situation where wluma would think you are intentionally increasing brightness manually in a totally dark room and will learn to do it, whereas in practice someone turned on the lights in the room, and als thread simply is not refreshing fast enough to spot this. This is already a problem with webcam als.

I am not sure yet what is the best way to solve this, maybe the predictor should also have access to the age information (how old are these measurements), maybe force read the current als the moment user starts changing brightness. It is furthermore complicated by the fact that some drivers lie, and require several consequent reads of the file before the file actually begins to contain true als value...

[wolf-yuan-6115]

Okay great, thanks! This is a surprisingly complicated topic to get right, I want to focus on it at some point, but I don't know yet when I'll have a chance. I hope you don't mind running a locally compiled wluma with the patch for the time being?

The big problem with just making this value configurable is that this can totally mess up the training data - with your value of 500 the chance is small, but I still want to get it right if we open this for general public. Right now, wluma has multiple parallel threads, one is watching als, another is watching brightness changes, another is watching screen contents, and yet another is trying to make the decisions based on all those factors. And the danger is that with a bad luck you can get into a situation where wluma would think you are intentionally increasing brightness manually in a totally dark room and will learn to do it, whereas in practice someone turned on the lights in the room, and als thread simply is not refreshing fast enough to spot this. This is already a problem with webcam als.

I am not sure yet what is the best way to solve this, maybe the predictor should also have access to the age information (how old are these measurements), maybe force read the current als the moment user starts changing brightness. It is furthermore complicated by the fact that some drivers lie, and require several consequent reads of the file before the file actually begins to contain true als value...

Thanks for looking into this issue, take your time! I wouldn't mind to compile wluma w/ patches :D