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

From: big . block0203

Date: Fri May 15 2026 - 14:38:49 EST

Hi Jonathan,

Following up: PNP0C60 is not what I read it as initially. Per Microsoft's
ACPI/GPIO button documentation, _CID PNP0C60 is the laptop/slate mode
state indicator (the soc_button_array binding you mentioned). The
matching ACPI ID for an ALS is ACPI0008, and that device is not present
anywhere in this machine's namespace.

The laptop has a small unidentified optical element in the top bezel
beside the camera assembly that may be an ALS — but the ACPI side
doesn't expose anything named like one. A walk of the LEN* and INT33D3
devices on this system:

LEN0071:00 status=? driver=i8042 kbd (TrackPoint keyboard)
LEN009F:00 status=0 driver=NONE (disabled by firmware)
LEN0100:00 status=15 driver=NONE
LEN0111:00 status=15 driver=NONE
LEN0112:00 status=15 driver=NONE
LEN0130:00 status=15 driver=NONE (Fn / Function Keys per Lenovo Windows driver naming)
LEN0140:00 status=0 driver=NONE (disabled by firmware)
LEN0268:00 status=15 driver=NONE (ThinkPad HKEY; thinkpad_acpi matches this HID)
LEN0310:00 status=? driver=i8042 aux (TrackPoint pointing device)
INT33D3:00 status=15 driver=NONE

(driver= taken from physical_node/driver. thinkpad_acpi registers via
the ACPI bus rather than creating a platform-bus binding, so it doesn't
appear here even though it uses LEN0268.)

LEN0100, LEN0111, LEN0112 are the genuine unknowns. No IPU6 / INT3472
stack is present either — this SKU's camera is a UVC device on USB
(Chicony 04f2:b7e0, uvcvideo), so the ALS, if there is one, isn't
behind that path.

This looks like a thinkpad_acpi / platform-driver-x86 question rather
than an IIO one. I'll continue the discussion there. Thanks for the
help narrowing it down — pointing at the cid field is what got us here.

Regards,
big.block

On Fri, May 15, 2026, at 15:47, Jonathan Cameron wrote:
> On Fri, 15 May 2026 14:51:09 +0400
> big.block0203@xxxxxxxxxxxx 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
>
>