FW16, linux: ambient light sensor (ALS) does not work when queried just after resume from sleep

[colingeniet]

Device Information

System Model or SKU

Framework Laptop 16 (AMD Ryzen™ 7040 Series)

BIOS VERSION

4.03

DIY Edition information

Memory: Kingston KF556S40IBK2-32
Storage: Crucial CT2000T500SSD8

Standalone Operation (Laptop Only)

Are you running your mainboard as a standalone device. Is standalone mode enabled in the BIOS?

• Yes
• No

Describe the bug

When accessing the ALS through linux sysfs (/sys/bus/iio/devices/iio:device0/in_illuminance_raw),
reading the ALS just after resuming from sleep causes it to output 0.
If read frequently enough, it will keep answering 0.
Not reading for a few seconds allows it to recover, after which it works normally.

Steps To Reproduce

• have a process frequently (~every 2sec) read the ALS from linux sysfs
• suspend computer, and resume
• after resume, ALS will always output '0'
• if reading process is stopped for ~5sec, the ALS 'recovers', and will work normally again

Example in shell:

$ while true; do
    cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw; sleep 2;
done
# output:
2002
1976
1948
1927
# Suspend computer here, and resume
0
0
0
0
^Z # stop reading process, wait for a few seconds
fg # restart reading
2196
2135
2075
2038

Expected behavior

correct value when reading /sys/bus/iio/devices/iio:device0/in_illuminance_raw

Operating System (please complete the following information):

• OS/Distribution: archlinux
• Version: n/a
• Linux Kernel Version: Linux 6.18.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Mon, 09 Feb 2026 17:16:33 +0000 x86_64 GNU/Linux

Additional context

Forum thread: https://community.frame.work/t/ambient-light-sensor-does-not-work-after-resume/75799

BIOS / Kernel versions:
The same problem exists with BIOS 3.05, 3.07, kernel 6.16.8-arch3-1
I am not aware of any versions for which this problem does not exist.

In the above thread, someone suggested a different way to read the ALS, through /dev/port.
When I tested it back then, /dev/port gave the correct value, while /sys/bus/iio/devices/iio:device0/in_illuminance_raw gave the wrong one.
Linux kernel might be the culprit?
(I tried testing it again, but the method they suggested crashes my computer now!)

Edit for extra info:

• Here's a dmesg trace while running the test described in "Steps To Reproduce". https://github.com/user-attachments/files/25263869/dmesg.txt
• This has been reported on the linux kernel bug tracker by someone else: https://bugzilla.kernel.org/show_bug.cgi?id=220867. From their report, this also affects the FW13 R7840U. No answer on that side.

[JohnAZoidberg]

Oh this looks like a secondary symptom on top of: FrameworkComputer/EmbeddedController#73

What software are you using? I understand that you are debugging by using cat, but in practice what software has issues with this behavior?

[JohnAZoidberg]

In the above thread, someone suggested a different way to read the ALS, through /dev/port.

How exactly?

[colingeniet]

Oh this looks like a secondary sympton on top of: FrameworkComputer/EmbeddedController#73

Yes! Guess I checked the wrong issue tracker for existing reports... Sorry

What software are you using? I understand that you are debugging by using cat, but in practice what software has issues with this behavior?

wluma (https://github.com/max-baz/wluma). It does use the /sys/bus/iio file.

In the above thread, someone suggested a different way to read the ALS, through /dev/port.

How exactly?

It was xxd -seek 0xE80 -l 2 /dev/port
https://community.frame.work/t/ambient-light-sensor-does-not-work-after-resume/75799/5?u=linop

The other issue you linked made me check with framework_tool --sensors: it is not affected (meaning that /sys/.../in_illuminance_raw will report 0, while at the same time framework_tool gives the correct value)

[JohnAZoidberg]

Yes! Guess I checked the wrong issue tracker for existing reports... Sorry

No this one is the right one here.

The other issue you linked made me check with framework_tool --sensors: it is not affected (meaning that /sys/.../in_illuminance_raw will report 0, while at the same time framework_tool gives the correct value)

framework_tool also talks to the EC directly via ports/memmap, bypassing the HID reports.
But it does it in a way that works on all Framework systems, your xxd command is not safe on all and may crash them - important to know for anyone else reading this.

wluma (https://github.com/max-baz/wluma). It does use the /sys/bus/iio file.

Ah yes okay, hmm. That goes through the kernel, which uses the HID interface from EC.

[JohnAZoidberg]

I cannot reproduce on Laptop 16 AI 300 by doing:

$ while true; do
    cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw; sleep 2;
done

I always get valid measurements.
I made sure to systemctl stop iio-sensor-proxy so that nothing else is reading from there.

[colingeniet]

I cannot reproduce on Laptop 16 AI 300

Hmm, not sure if there might be a difference between 1st and 2nd gen FW16.
FW13 amd R7840U and FW13 intel 7 155H are also affected according to these:
https://lore.kernel.org/all/bug-220867-217253@https.bugzilla.kernel.org%2F/
FrameworkComputer/EmbeddedController#73

I realise I wasn't very specific about the "suspend" part. I'm using systemctl suspend, if it matters.

[JohnAZoidberg]

Ok I can reproduce it now after masking iio-sensor-proxy and I think I found the issue in the EC firmware.

Hmm, not sure if there might be a difference between 1st and 2nd gen FW16.

The code for that is the same on all recent systems so they all would be affected.