Re: [BUG] ACPI INT33D3 ambient light sensor not bound on Intel Lunar Lake (ThinkPad X1 Carbon Gen 13)

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 15 May 2026 14:51:09 +0400
big.block0203@fastmail.com wrote:

> Hi,
> 
> On a Lenovo ThinkPad X1 Carbon Gen 13 (Intel Lunar Lake), the ACPI
> firmware declares an INT33D3 ambient light sensor as present, enabled,
> and functional, but no Linux driver binds to it. As a result, no IIO
> device is created and no ambient light data is available to userspace
> (KDE/GNOME auto-brightness, iio-sensor-proxy, etc.).

So INT33D3 is a new ID to IIO at least but looks like it
binds to drivers/input/misc/soc_button_array.c 

So I'm guessing not an ALS unless that's a multipurpose chip - seems
unlikely though as that combination isn't common.

So if there is an ambient light sensor here that is exposed to
the OS we need to find it amongst the other IDs..

> 
> I did not find an existing report covering this on Lunar Lake. Apologies
> if this duplicates one I missed; pointers welcome.
> 
> Hardware
> ========
> - Lenovo ThinkPad X1 Carbon Gen 13
> - Intel Core Ultra 7 258V (Lunar Lake, Xe2)
> - iGPU: PCI 8086:64a0 (rev 04), subsystem 17aa:2339
> - Panel: Samsung Display ATNA40YK20-0 (2.8K OLED)
> 
> Software
> ========
> - Fedora Kinoite 44
> - kernel 7.0.6-200.fc44.x86_64
> - KDE Plasma 6 on Wayland
> 
> Symptom
> =======
> No IIO devices are exposed at all:
> 
>     $ ls /sys/bus/iio/devices/
>     (empty)
>     $ ls /sys/class/iio/
>     (empty)
> 
> But the ALS is declared in ACPI:
> 
>     $ cat /sys/bus/acpi/devices/INT33D3:00/hid
>     INT33D3
> 
>     $ cat /sys/bus/acpi/devices/INT33D3:00/status
>     15
> 
>     $ ls /sys/bus/acpi/devices/INT33D3:00/
>     cid  hid  modalias  path  physical_node  power  status  subsystem  uevent
>     # No `driver` symlink under physical_node — nothing bound.
> 
>     $ readlink /sys/bus/acpi/devices/INT33D3:00/physical_node
>     ../../../../../../pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D3:00
> 
>     $ sudo dmesg | grep -i INT33D3
>     (no output — no driver even attempted to probe)
> 
> Status 0xf per ACPI spec means: present (bit 0), enabled (bit 1), shown
> in UI (bit 2), functional (bit 3). The firmware unambiguously declares
> the device as available. dmesg shows no probe attempt and no error.
> 
> Other unclaimed firmware-declared devices on this platform (for context)
> ========================================================================
>     INTC1025:00     status=?    driver=NONE
>     INTC105D:00     status=15   driver=intel-pinctrl
>     INTC105D:01     status=15   driver=intel-pinctrl
>     INTC105D:02     status=15   driver=intel-pinctrl
>     INTC105D:03     status=15   driver=intel-pinctrl
>     INTC105D:04     status=15   driver=intel-pinctrl
>     INTC1068:00     status=15   driver=int3400 thermal
>     INTC1069:00     status=15   driver=int3403 thermal
>     INTC1069:01     status=15   driver=int3403 thermal
>     INTC1069:02     status=15   driver=int3403 thermal
>     INTC1069:03     status=15   driver=int3403 thermal
>     INTC1069:04     status=15   driver=int3403 thermal
>     INTC107B:00     status=15   driver=intel-hid

It's more than possible that the ALS is presented as part of the HID.

>     INTC1092:00     status=0    driver=NONE
not 100% sure but there are some references to a wireless modem related
thing associated with this ID.

>     INTC109D:00     status=15   driver=NONE
Might be the watchdog.  Maybe see if it has a cid entry.


Other alternatives would be it's on a discoverable bus...

So without figuring out where it is, not much we can do here.

Good luck on finding more info!

Jonathan


> 
> INTC109D:00 is also present-and-enabled but has no driver bound. Its
> function is unknown to me; including it for awareness in case it is
> sensor-hub-related and a prerequisite for INT33D3.
> 
> INT3519:00 is also present in ACPI but with status=0 (disabled by
> firmware), so likely not relevant here.
> 
> Expected behavior
> ==================
> An IIO device of class `in_illuminance*` should appear under
> /sys/bus/iio/devices/, allowing iio-sensor-proxy and desktop
> environments to consume ambient light data for auto-brightness.
> 
> Thanks,
> big.block