Ambient light sensor does not work after resume

Framework Laptop 16 Linux
1

After resuming from suspend, the ALS stops working:
cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw
just returns 0. There also is no delay in reading this file (whereas there is a significant read delay when the ALS actually works.)

The issue almost always happens after a resume.
When the ALS is borked, suspending & resuming again will sometimes “fix” it, but this is very unreliable.

I’m not seeing anything relevant in dmesg.

Is anyone else experiencing this? I’m not sure how to go about debugging this, so any suggestion would be welcome.

versions:

Fw16 w/ R7840
BIOS: 3.07
distro: archlinux
kernel: 6.16.8-arch3-1

I am not aware of previous kernel/BIOS versions for which the issue did not exist.

2

Seems to be working just fine for me. I don’t use this functionality but tested the cat command you listed and it works, even after a suspend/resume.

Fw16 w/ 7940HS
BIOS: 3.05
distro: archlinux
kernel: 6.16.8-arch3-1

1 Like
3

Turns out that was the key difference! If I disable the light-adjusting-thingy (wluma in my case), then the ALS starts working again.

Somehow the ALS doesn’t seem to enjoy being hammered by requests from wluma just after resuming. I think it queries it at quite a high rate (10/s maybe?), I’ll look into that.

Downgrading to 3.05 BIOS didn’t change anything

2 Likes
4

You could try reading the ALS from the EC memmap directly using sudo xxd -seek 0xE80 -l 2 /dev/port (it’s little endian and hex but 0 should be obvious), and that should narrow it down as a kernel issue or EC issue.

1 Like
5

Thanks, that’s a great tool! Looks like kernel side:

$ cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw
0
$ sudo xxd -seek 0xE80 -l 2 /dev/port                    
00000e80: c800
1 Like
6

Something I didn’t think about, is the kernel gets it’s data from ACPI (I think). So it could still be an EC or maybe BIOS issue, but at least we know the EC is reading the ALS successfully!

7

I’m seeing the hid_sensor_als kernel module loaded, I assume that’s the one being used.

8

Based on my FW13 7840U, I think it might actually read the ALS via the AMD sensor fusion hub (amd_afh), I’m not too sure how any of that works though. Open an issue on the issue tracker and hopefully someone from Framework can look into it.

Anyway the ALS is physically connected to the EC, and we can read it directly from that, so as a workaround I’ve added ALS support to my als branch of Dustin’s framework-laptop-kmod driver. You will probably have to blacklist hid_sensor_als, if you can’t get your software to pick the right sensor.

9

Same here, and thanks for the tip! Stopping illuminanced (in my case) for a moment and then restarting it gets the ALS working after sleep. A more permanent solution would certainly be nice, though.

1 Like
10

Slightly more permanent solution: I’ve found (purely through trial and error) that setting illuminanced to check the ALS every 4 seconds seems to give it enough time to come out of sleep successfully. For all I know, this might be tied to how quickly your device resumes, so that four-second interval might not work for everyone.

1 Like
11

I have the same problem - after resume from suspend I can only read 0.

[60174.178490] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60174.182228] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60175.191078] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60175.195410] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60176.205519] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60176.209844] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60177.219826] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60177.224049] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60178.233346] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60178.237837] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60179.246911] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found
[60179.251291] hid-sensor-hub 0018:32AC:001B.0002: No report with id 0xffffffff found

FW13 on arch / kernel 6.19.10-arch1-1

Dis- and re-enabling the automatic brightness adapt function in plasma display configuration restarted the iio-sensor-proxy, and the sysfs entry also resumed working.

Apr 01 10:33:51 abigail kernel: hid-sensor-hub 0018:32AC:001B.0002: hidraw1: I2C HID v1.00 Device [FRMW0005:00 32AC:001B] on i2c-FRMW0005:00
…
❯ systemctl status iio-sensor-proxy.service 
● iio-sensor-proxy.service - IIO Sensor Proxy service
     Loaded: loaded (/usr/lib/systemd/system/iio-sensor-proxy.service; static)
     Active: active (running) since Wed 2026-04-01 10:33:54 CEST; 4 days ago
 Invocation: 357f7d2270fb4e0b982a79314c8e6128
   Main PID: 1740 (iio-sensor-prox)
      Tasks: 4 (limit: 37599)
     Memory: 1.5M (peak: 8.6M, swap: 628K, swap peak: 880K)
        CPU: 19.960s
     CGroup: /system.slice/iio-sensor-proxy.service
             └─1740 /usr/lib/iio-sensor-proxy

Apr 01 10:33:53 abigail systemd[1]: Starting IIO Sensor Proxy service...
Apr 01 10:33:54 abigail systemd[1]: Started IIO Sensor Proxy service.
Apr 01 10:33:54 abigail iio-sensor-proxy[1740]: Buffer '/dev/iio:device0' did not have data within 0.5s

And now it works even after suspend and resume. So, no further digging into the problem possible for now…