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

[maximbaz]

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

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