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

[big.block0203@fastmail.com]

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@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
> 
>