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

wluma/src/als/iio.rs

Lines 75 to 78 in 55d98fe

	let raw = self.get_raw()?;
	let profile = super::find_profile(raw, &self.thresholds);
	log::trace!("ALS (iio): {} ({})", profile, raw);

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?

wluma/src/als/iio.rs

Lines 85 to 101 in 55d98fe

	Ok(Illuminance {
	value: Mutex::new(open_file("in_illuminance_raw")?),
	scale: open_file("in_illuminance_scale")
	.and_then(|mut f| read(&mut f))
	.unwrap_or(1_f64),
	offset: open_file("in_illuminance_offset")
	.and_then(|mut f| read(&mut f))
	.unwrap_or(0_f64),
	})
	}
	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"))?),

[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 😞 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.