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

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

[big.block0203]

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.).

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
    INTC1092:00     status=0    driver=NONE
    INTC109D:00     status=15   driver=NONE

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

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

[Jonathan Cameron]

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

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

[big.block0203]

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