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