'predictor-eDP-1' panicked at 'Did not receive initial ALS value in time' on Microsoft Surface Pro 8

[HamzaTGP]

Steps for reproducing the issue

Running wluma (either as super user or normal user)

What is the buggy behavior?

Program waits 5 seconds before outputting the following error message within the terminal: thread 'predictor-eDP-1' panicked at 'Did not receive initial ALS value in time', src/predictor/controller.rs:62:25

What is the expected behavior?

Expected behavior is the program running normally without any error messages

Logs

[2023-08-21T23:36:10Z DEBUG wluma] Using Config {
        als: Iio {
            path: "/sys/bus/iio/devices",
            thresholds: {
                80: "dim",
                500: "bright",
                0: "night",
                800: "outdoors",
                250: "normal",
                20: "dark",
            },
        },
        output: [
            Backlight(
                BacklightOutput {
                    name: "eDP-1",
                    path: "/sys/class/backlight/intel_backlight",
                    capturer: None,
                    min_brightness: 1,
                },
            ),
        ],
    }
[2023-08-21T23:36:10Z INFO  wluma] Continue adjusting brightness and wluma will learn your preference over time.
thread 'predictor-eDP-1' panicked at 'Did not receive initial ALS value in time', src/predictor/controller.rs:62:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Version

I installed the program using the wluma AUR package. I am running version 4.3.0-1

Environment

LSB Version:    n/a
Distributor ID: Arch
Description:    Arch Linux
Release:    rolling
Codename:   n/a
Linux TGP-Surface 6.4.7-arch1-1-surface #1 SMP PREEMPT_DYNAMIC Fri, 28 Jul 2023 17:35:22 +0000 x86_64 GNU/Linux
egrep: warning: egrep is obsolescent; using grep -E
clang 15.0.7-9
lib32-vulkan-icd-loader 1.3.255-1
rust 1:1.71.1-1
vulkan-headers 1:1.3.257-1
vulkan-icd-loader 1.3.255-1
vulkan-intel 1:23.1.6-1
egrep: warning: egrep is obsolescent; using grep -E

[maximbaz]

My first guess would be that this part of the code hangs:

https://github.com/maximbaz/wluma/blob/55d98fe97c39a13a6bddd991351e9ef8503ef84b/src/als/iio.rs#L75-L78

Could you run with RUST_LOG=trace, to see for example if the ALS value is being read?

I'm not quite sure if a file read could even hang like this... But worth a try? Could you explore your /sys/bus/iio/devices, find the folder where file name would contain als, and in that folder try to cat these files (whatever exist) and see if this works?

https://github.com/maximbaz/wluma/blob/55d98fe97c39a13a6bddd991351e9ef8503ef84b/src/als/iio.rs#L85-L101

[HamzaTGP]

Hello. Apologies for the late response as I switched distributions from Arch to Fedora Workstation on my Surface. Problem still persists.

Here is the output of wluma when ran with RUST_LOG=trace:

[2023-08-27T19:28:01Z DEBUG wluma] Using Config {
        als: Iio {
            path: "/sys/bus/iio/devices",
            thresholds: {
                80: "dim",
                0: "night",
                20: "dark",
                500: "bright",
                800: "outdoors",
                250: "normal",
            },
        },
        output: [
            Backlight(
                BacklightOutput {
                    name: "eDP-1",
                    path: "/sys/class/backlight/intel_backlight",
                    capturer: None,
                    min_brightness: 1,
                },
            ),
        ],
    }
[2023-08-27T19:28:01Z INFO  wluma] Continue adjusting brightness and wluma will learn your preference over time.
thread 'predictor-eDP-1' panicked at 'Did not receive initial ALS value in time', src/predictor/controller.rs:62:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I followed what you outlined; I first searched for name file in /sys/bus/iio/devices which contains als (which in my case happened to be /sys/bus/iio/devices/iio:device5), then I entered that directory and ran cat on all the files mentioned within the code snippet you showed me. All where there except the last three

 fn parse_intensity(path: PathBuf) -> Result<SensorType, Box<dyn Error>> { 
     Ok(Intensity { 
         r: Mutex::new(File::open(path.join("in_intensity_red_raw"))?), 
         g: Mutex::new(File::open(path.join("in_intensity_green_raw"))?), 
         b: Mutex::new(File::open(path.join("in_intensity_blue_raw"))?), 

The 3 files specified in this snippet cease to exist.

[maximbaz]

Hello! Sorry, this entirely slipped my attention :disappointed: Are you still interested to debug this further? If so, given that you have the device files, can you actually read the values inside them?

cat /sys/bus/iio/devices/iio:deviceN/in_illuminance_raw
cat /sys/bus/iio/devices/iio:deviceN/in_illuminance_scale
cat /sys/bus/iio/devices/iio:deviceN/in_illuminance_offset

ls -al /sys/bus/iio/devices/iio:deviceN/in_illuminance_raw
ls -al /sys/bus/iio/devices/iio:deviceN/in_illuminance_scale
ls -al /sys/bus/iio/devices/iio:deviceN/in_illuminance_offset

groups

This would additionally list permissions and ownership of the files, to make sure that your user has the necessary access. Redact the sensitive info (e.g. groups) as necessary.