[POLL/HELP] AMD FW 13 als/Illuminance sensor - present/populated?

Framework Laptop 13
,
1

Hi there I am trying to Bisect an issue with my framework relating to the ALS / Luminance sensor which is meant to be present and at least for some users is populating just fine with the mainline and supported Capella CM3218 Chip .

Some debug info in here [GUIDE] Linux battery life tuning - #439 by jwp

If you have an AMD Framework it would be helpful if I can get an idea if this is working for everyone but me or if there is an issue with QA generally.

Framework Edition you have:

  • AMD FW 7840U
  • AMD FW 7640U

0 voters

Do you have a SysFS Entry for the Ambient Light Sensor appear i.e on linux this should be populated : /sys/bus/iio/devices/iio:device0/in_illuminance_raw

  • Yes my ALS is working
  • No I do not have an IIO/ALS Entry

0 voters

OS / Kernel you are running:

  • Fedora 39
  • Fedora 38
  • Fedora Rawhide
  • Fedora 39 with Custom Kernel
  • Arch
  • Ubuntu
  • Ubuntu with OEM Kernel
  • Other (Please add comment)
  • Windows

0 voters

`
Some useful debug commands / output references:

Poll the iio sensor proxy for known sensors/run in foreground (likely needs root)

sudo /usr/libexec/iio-sensor-proxy -v -r

Show the IIO bus device status at entry 1

sudo iio_generic_buffer -A -N 0

Dump udev devices matching iio category

udevadm info --export-db|grep -A5 -B2 iio

Look in dmesg for als messages:

dmesg |grep als

List loaded modules for sensor deps

lsmod |grep als
2

So I have just reseated the ribbon cable/PCB Sensor/Webcam assembly per : Webcam Replacement Guide - Framework Guides

  • with no Joy. I am relatively confident I have received a DOA sensor at this point. Thanks to those who responded.

image
image605×1345 104 KB

image
image605×1345 98.2 KB

image
image605×1345 117 KB

3

On 7840U with Secure Boot on, Webcam switched off, sensor appears and is working:

$ sudo /usr/libexec/iio-sensor-proxy -v -r
** (iio-sensor-proxy:11319): DEBUG: 09:38:58.145: Light read from IIO on 'iio:device0': 155 (scale 1,000000) = 155,000000
** (iio-sensor-proxy:11319): DEBUG: 09:38:58.145: Light level sent by driver (quirk applied): 155,000000 (unit: lux)
** (iio-sensor-proxy:11319): DEBUG: 09:38:58.146: Emitted light changed: from 154,000000 to 155,000000
** (iio-sensor-proxy:11319): DEBUG: 09:38:58.847: process_scan_1: channel_index: 0, chan_name: in_intensity_both, channel_data_index: 0 location: 0 bytes: 4 is_signed: 1 be: 0 shift: 0 bits_used: 16
** (iio-sensor-proxy:11319): DEBUG: 09:38:58.847: Light read from IIO on 'iio:device0': 155 (scale 1,000000) = 155,000000
** (iio-sensor-proxy:11319): DEBUG: 09:38:58.847: Light level sent by driver (quirk applied): 155,000000 (unit: lux)
** (iio-sensor-proxy:11319): DEBUG: 09:38:59.548: process_scan_1: channel_index: 0, chan_name: in_intensity_both, channel_data_index: 0 location: 0 bytes: 4 is_signed: 1 be: 0 shift: 0 bits_used: 16

$ sudo iio_generic_buffer -A -N 0
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_intensity_both_en
Failed to enable/disable in_intensity_both_en
Enabling: in_illuminance_en
Failed to enable/disable in_illuminance_en
Enabling: in_timestamp_en
Failed to enable/disable in_timestamp_en
/sys/bus/iio/devices/iio:device0 als-dev0
Failed to write current_trigger file
Disabling: in_intensity_both_en
Disabling: in_illuminance_en
Disabling: in_timestamp_en

$ udevadm info --export-db|grep -A5 -B2 iio
E: ID_PATH_TAG=platform-AMDI0010_00-platform-HID-SENSOR-200041_1_auto

P: /devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0003/HID-SENSOR-200041.1.auto/iio:device0
M: iio:device0
R: 0
U: iio
T: iio_device
D: c 234:0
N: iio:device0
L: 0
E: DEVPATH=/devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0003/HID-SENSOR-200041.1.auto/iio:device0
E: SUBSYSTEM=iio
E: DEVNAME=/dev/iio:device0
E: DEVTYPE=iio_device
E: MAJOR=234
E: MINOR=0
E: USEC_INITIALIZED=14691043
E: IIO_SENSOR_PROXY_TYPE=iio-poll-als iio-buffer-als
E: SYSTEMD_WANTS=iio-sensor-proxy.service
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

P: /devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0003/HID-SENSOR-200041.1.auto/trigger0
M: trigger0
R: 0
U: iio
E: DEVPATH=/devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0003/HID-SENSOR-200041.1.auto/trigger0
E: SUBSYSTEM=iio

P: /devices/platform/AMDI0010:03
M: AMDI0010:03
R: 03

$ dmesg |grep als


$ lsmod |grep als
hid_sensor_als         16384  0
hid_sensor_trigger     20480  2 hid_sensor_als
hid_sensor_iio_common    20480  2 hid_sensor_trigger,hid_sensor_als
industrialio          131072  4 industrialio_triggered_buffer,hid_sensor_trigger,kfifo_buf,hid_sensor_als
hid_sensor_hub         32768  3 hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_als

Hope this helps,

/herodot

4

Thanks - it seems that this is a QA Defect as about 20% of respondents are not getting the ALS sensor populate. Can someone at framework please pick this up

5

So the sensor was working OOTB on a Fedora 39 Live System with Gnome, and it made the screen brighter and darker. On Gentoo with sway it’s not doing anything with the screen yet (I assume I need to setup something for that first, which then actually reads the sensor, but I didn’t have time to look into details for that yet), but the sensor is there in /sys/bus/iio/devices/iio:device0/in_illuminance_raw and the value goes up and down if I shine light at the sensor or cover it.

Both on Fedora and on Gentoo I think it’s using the hid_sensor_als kernel module. I don’t have the cm32181 module compiled on Gentoo.

1 Like
6

Yeah it’s definitely hardware issue for my fw13; I guess in the scheme of things it being the only DOA bit is relatively benign ; but irritating.

7

So as an update.

Yesterday I did an install of 23.10 out of curiosity.

Because Ubuntu does not support installation to btrfs subvolumes I had to format my swap partition temporarily to allow it some space on my drive. The Ubuntu installer pulled in the vfat ESP/EFI partition and decided it was going to format it as part of the process. Annoying but not catastrophic to the various ditros and experiments sitting on my btrfs root

Low and behold, on boot the ALS sensor decided to miraculously appear.

Now what caused this to disappear/not appear in the first place is what I am wondering.

The history of getting the FW13 until today looks like this:

Day0 - Install Fedora FC39 KDE from Nightly compose (2 days prior to GA). fwupd of the shipped firmware bits to 3.03

Day2-4- Install Ublue/Silverblue,Bazzite - ostree experiments. Install Nobara 38 / Windows 11 - Then full wipe; install Fedora 39 (Workstation Release) - Realise als has been missing . Do an EFI reflash of 3.03 firmwares manually.

Day5 - Rebase dnf sysupgrade F39 to Rawhide

From rawhide I had a fc39 root subvolume as well as the rawhide userspace which I switched between when testing kernels and patches.

The only thing that stayed consistent from Day 0 was the EFI partition, up until ubuntu 23.10 helpfully nuked it.

So I am wondering if there potentially was some efivars or something which got reset when that happened.

A clean install of FC39 userspace on a new subvolume since and the als continues to work.

8

Just wanted to comment als shows up for me, using NixOS Unstable with 6.6.1 kernel.

9

Shows up just fine on my Framework - AMD 7840U DIY.

Gentoo Linux, kernel 6.1.57.

As far as I can tell it’s using generic ACPI / HID driver as I have all Capella related modules disabled in my kernel config, notably CONFIG_CM32181=n. In fact, I only have the following modules available:

Device Drivers  --->
  <M> Industrial I/O support  --->
    Light sensors  --->
      <M> ACPI Ambient Light Sensor  # CONFIG_ACPI_ALS=m
      <M> HID ALS                    # CONFIG_HID_SENSOR_ALS=m
      <M> HID PROX                   # CONFIG_HID_SENSOR_PROX=m

$ lsmod | grep als
hid_sensor_als         20480  0
hid_sensor_trigger     20480  2 hid_sensor_als
hid_sensor_iio_common    24576  2 hid_sensor_trigger,hid_sensor_als
industrialio          110592  4 industrialio_triggered_buffer,hid_sensor_trigger,kfifo_buf,hid_sensor_als
hid_sensor_hub         28672  3 hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_als

$ ls /sys/bus/iio/devices/iio:device0/*illuminance*
/sys/bus/iio/devices/iio:device0/in_illuminance_hysteresis
/sys/bus/iio/devices/iio:device0/in_illuminance_hysteresis_relative
/sys/bus/iio/devices/iio:device0/in_illuminance_offset
/sys/bus/iio/devices/iio:device0/in_illuminance_raw
/sys/bus/iio/devices/iio:device0/in_illuminance_sampling_frequency
/sys/bus/iio/devices/iio:device0/in_illuminance_scale

Value of in_illuminance_raw changes when covering the small sensor hole on the bezel.

No dmesg entries re "iio" or "als", udevadm output same as the one above by @herodot .

The one thing I can recommend, in particular as a result of the kernel module situation, would be to blacklist Capella related modules on your preferred choice of distro and see if the generic ACPI / HID drivers would pick it up.

Edit: Confirmed working with just ACPI / HID IIO kernel modules.

10

Sounds like a Linux issue instead of a QA issue to me.
Should I mark this thread as closed?

11

I think I may have tracked it down to the upstream kernel scripts for how modules get packaged during ; make modules_install step. Possibly to do with the .AUTO bit in the dmesg?

The exact same kernel built from an exploded tree and manually installed and built into an RPM and installed exhibit different behaviour ; I had a bunch of distro kernels built from exploded trees to apply the EC patches which is probably where I got came unstuck.

Yes please go ahead and close.