Repository navigation
ALS sensor dead after resume #73
Description
On a Intel 13" (Intel(R) Core(TM) Ultra 7 155H) the ALS sensor is dead after the first/suspend resume making it pretty much unusable:
$ sudo linux/tools/iio/iio_generic_buffer -a --device-name als
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_intensity_both_en
Enabling: in_illuminance_en
Enabling: in_timestamp_en
/sys/bus/iio/devices/iio:device0 als-dev0
339.000000 339.000000 1761832980102457343
339.000000 339.000000 1761832980903336181
Disabling: in_intensity_both_en
Disabling: in_illuminance_en
Disabling: in_timestamp_en
Suspend and resume device:
$ sudo linux/tools/iio/iio_generic_buffer -a --device-name als
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_intensity_both_en
Enabling: in_illuminance_en
Enabling: in_timestamp_en
/sys/bus/iio/devices/iio:device0 als-dev0
^^^^ hangs here until CTRL-C is hit
Disabling: in_intensity_both_en
Disabling: in_illuminance_en
Disabling: in_timestamp_en
The same is reproducible with iio-sensor-proxy (I picked iio_generic_buffer as it requires less indirection)
dmidecode reports the Bios as Release Date: 08/08/2025 and fwupdmgr doesn't report any updates to install.
ectool says
$ sudo build/hx30/util/ectool version
RO version: marigold-3.0.5-a5f07f8
RW version: marigold-3.0.5-a5f07f8
Firmware copy: RO
Build info: marigold-3.0.5-a5f07f8 2025-08-06 07:01:52 marigold1@ip-172-26-3-226
Tool version: v0.0.1-f6620a8 2025-05-28 11:32:28 agx@quark
Activity
JohnAZoidberg commentedon Oct 30, 2025
What's your kernel and iio-sensor-proxy version?
Does it work if you directly access it with framework_tool?
https://github.com/FrameworkComputer/framework-system/blob/main/EXAMPLES.md#check-sensors
agx commentedon Oct 30, 2025
iio-sensor-proxy 3.8 (but see the above reproducer with
iio_generic_buffer). Kernel is 6.16.12.Going via
/dev/crosseems to work:would be good to have the
framework_toolin Debian (and thus its downstreams).JohnAZoidberg commentedon Oct 31, 2025
Are there any related error messages in dmesg?
The ALS Sensor works by the EC exposing an I2C HID interface.
This is the first time I've seen this issue happen. It's been pretty solid so far
agx commentedon Oct 31, 2025
This is the dmesg from a suspend/resume cycle:
Likely because most DEs don't unclaim the sensor. It seems stable if you keep the sensor claimed across suspend/resumed (e.g. have iio-sensor-proxy + monitor-sensor running). If the DE unclaims the sensor on e.g. screen blank (which we do in phosh) and don't have anything else claiming the sensor it seems to break (but works fine on e.g. the SDM845's sensor core on phones which suspends/resumes a ton more often).
agx commentedon Nov 2, 2025
Interesting, reloading
i2c_hid_acpiunbreaks after resume unbreaks things (until next suspend)JohnAZoidberg commentedon Nov 2, 2025
Interesting findings!
You're using phosh on the framework laptop?
Why does it unclaim the sensor? Would that help with power consumption?
Have you always seen this or could this be a regression with recent kernels?
agx commentedon Nov 2, 2025
Yes
Unclaiming the sensor when the screen is blanked saves battery by reducing wakeups
I only enabled it recently so I cannot tell.
agx commentedon Nov 2, 2025
in
/usr/lib/systemd/system-sleep/framework13-als-workaroundseems to reliably work around the issue.JohnAZoidberg commentedon Nov 4, 2025
Can you try to downgrade to an earlier version of iOS sensor proxy?
This seems like your issue
https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/404#note_3099601
agx commentedon Nov 4, 2025
See how I wrote that the iio-buffer tools fail too. iio-sensor-proxy thus can't be at fault here as a suspend/resume must not break unrelated tools. It's a kernel problem (accidentally I'm one of iio-s-p upstreams).
alecbcs commentedon Nov 28, 2025
I'm also experiencing this issue on an AMD Framework 13 when using gnome-adaptive-brightness (issue linked above).
@agx's workaround script works for me, but does cause a momentary dip in brightness as the extension reads a zero value a couple times before the module is reloaded. (Note to others: don't forget to make the script executable
chmod ug+x <path>-- that caused me a couple minutes of debugging.)For reference I'm using Debian Unstable with kernel v6.17.9.
JohnAZoidberg commentedon Mar 2, 2026
Ok I can reproduce this issue, with
iio_generic_bufferno, as well as FrameworkComputer/SoftwareFirmwareIssueTracker#179I found an issue in the EC firmware and I'm testing a patch.
fain182 commentedon May 1, 2026
Related report from a Framework 13 AMD (Ryzen 7040 series) running Fedora 44, kernel 6.19.14.
On AMD, the issue manifests differently: the IIO buffer is silent from a fresh boot (not just after resume). The buffer driver in iio-sensor-proxy selects the buffer driver intermittently (sometimes
is_buffer_usable()passes within 0.5s, sometimes not), but even when selected, the buffer produces data only once and then goes silent — causingLightLevelto freeze on the initial value under stable light conditions.Direct sysfs reads work correctly at all times:
But the IIO buffer (
/dev/iio:device0) never produces continuous data, suggesting the EC firmware on AMD is not pushing buffer updates at regular intervals (only on the initial open, if at all).Workaround applied on our side: patched iio-sensor-proxy to skip the buffer driver for HID sensors and fall back to polling
in_illuminance_rawdirectly. Details at https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/work_items/433Mentioned here by the iio-sensor-proxy maintainer. Happy to test a firmware patch if one becomes available for AMD.