Ubuntu Concept ♥️ Snapdragon X Elite

Interesting — I compared your setup against mine, and the patch itself can’t be the difference. I checked the DTS node and the EC driver in the exact jglathe tree you linked (commit
9596aa60):

  • The embedded-controller@76 node there is functionally identical to mine (same reg, same GPIO 66 falling-edge interrupt). The extra “qcom,x1e-it8987-ec” compatible is unused — the driver’s of_match only lists “lenovo,yoga-slim7x-ec” — and the pinctrl entry I dropped for size reasons doesn’t matter for this.
  • The driver’s suspend hook is the same code: it writes EC register 0x23 ← 0x03 (screen off) then 0x23 ← 0x01 (suspend enter). That write is what makes the EC kill the keyboard backlight and blink the power LED, exactly like Windows does.

So if your LED stays solid and the backlight doesn’t go off, my bet is the driver isn’t probing at all – i.e. the DTB your system actually boots doesn’t contain the EC node, even though it’s in the source tree. Could you check:

ls -l /sys/bus/i2c/devices/\*-0076/driver   # should point to lenovo_yoga_slim7x
ls /sys/class/leds/                        # should list white:indicator

If *-0076 is missing or unbound, your boot path is loading a DTB without the node. Watch out for how the kernel image boots: if it’s a UKI (systemd-stub), the stub picks its own embedded .dtbauto DTB and silently overrides
anything GRUB loads via devicetree — that’s exactly the trap that cost me my first attempt (details in the gist).

That would also explain your numbers: your 2–3%/h saving would be coming from PSCI deep actually working on 7.1.2-jg-1 (nice — resume from deep is broken on the Ubuntu Concept 7.0.0-32 kernel), not from the EC notification. The two fixes should stack.

If the driver is bound and the LED still doesn’t blink, then something else differs — could you share your BIOS/EC firmware version in that case?

Here’s the dts the system loaded at boot, I think has the EC node: current_system.dts

This is the bios info:

BIOS Information

    Vendor: LENOVO

    Version: NHCN62WW

    Release Date: 12/02/2025

    ROM Size: 16 MB

    Characteristics:

            ACPI is supported

            Function key-initiated network boot is supported

            Targeted content distribution is supported

    BIOS Revision: 1.62

    Firmware Revision: 1.63

Driver and led: (there are drivers under -0076/subsystem/driver)

$ ls -l /sys/bus/i2c/devices/\*-0076/driver

ls: cannot access ‘/sys/bus/i2c/devices/*-0076/driver’: No such file or directory

$ ls /sys/class/leds/

input24::capslock input24::numlock input8::compose input8::scrolllock

input24::compose input24::scrolllock input8::kana white:indicator

I build my own uki using this script, it pulls the dtb from the kernel, which the jb-7.1.2 should have the patched dtb (I do this so I can boot in secure boot mode and use sd-boot instead of grub):

/etc/kernel/install.d/50-zboot-ukify.install

#!/bin/bash

set -e

# Arguments

COMMAND=“$1”

KERNEL_VERSION=“$2”

ENTRY_DIR_OR_PLUGIN=“$3”

KERNEL_IMAGE=“$4”

INITRD_FILE=“$5”

MACHINE_ID=$(cat /etc/machine-id)

if [[ -z “$INITRD_FILE” ]]; then

INITRD_FILE="/boot/initrd.img-${KERNEL_VERSION}"

fi

# Paths

UKI_DIR=“/boot/uki/EFI/Linux”

UKI_OUTPUT=“${UKI_DIR}/${KERNEL_VERSION}.efi”

# Uninstall Block

if [[ “$COMMAND” == “remove” ]]; then

rm -f "$UKI_OUTPUT"

echo "Removed UKI: $UKI_OUTPUT"

exit 0

elif [[ “$COMMAND” != “add” ]]; then

exit 0

fi

# Working Variables

RAW_KERNEL=“/tmp/Image-${KERNEL_VERSION}”

EXTRACT_TOOL=“/usr/src/linux-headers-${KERNEL_VERSION}/scripts/extract-vmlinux”

TMP_DTB_DIR=“/tmp/dtbs-${KERNEL_VERSION}”

# Keys

SB_KEY=“/etc/kernel/keys/eamon_db.key”

SB_CRT=“/etc/kernel/keys/eamon_db.crt”

mkdir -p “$UKI_DIR”

mkdir -p “$TMP_DTB_DIR”

# Extract DTB directly from kernel image

echo “Extracting DTB for $KERNEL_VERSION from kernel image…”

DTB_FILE=“”

# Parse objdump to get Size and File Offset for each .dtbauto section

while read -r size offset; do

\# Convert hex values from objdump to decimal for dd

size_dec=$((16#$size))

offset_dec=$((16#$offset))



tmp_dtb="$TMP_DTB_DIR/dtb\_${offset}.dtb"



\# Extract section

dd if="$KERNEL_IMAGE" of="$tmp_dtb" bs=1 skip="$offset_dec" count="$size_dec" status=none



\# Search binary for the Slim 7x compatible string

if grep -Faq "lenovo,yoga-slim7x" "$tmp_dtb"; then

    DTB_FILE="$tmp_dtb"

    echo "Found Slim 7x DTB embedded at offset $offset."

    break

fi

done < <(objdump -h “$KERNEL_IMAGE” | awk ‘/\.dtbauto/ {print $3, $6}’)

if [[ -z “$DTB_FILE” ]]; then

echo "Error: DTB for Yoga Slim 7x not found inside $KERNEL_IMAGE."

rm -rf "$TMP_DTB_DIR"

exit 1

fi

echo “Using system extract-vmlinux tool…”

if [[ ! -f “$EXTRACT_TOOL” ]]; then

echo "Error: $EXTRACT_TOOL not found. Ensure linux-headers-${KERNEL_VERSION} is installed."

rm -rf "$TMP_DTB_DIR"

exit 1

fi

# Extract the raw kernel

bash “$EXTRACT_TOOL” “$KERNEL_IMAGE” > “$RAW_KERNEL”

# — Command Line Generation —

# Read the base command line

STD_CMDLINE=$(cat /etc/kernel/cmdline)

# — os-release —

# Create the temporary os-release file

cat /etc/os-release > /tmp/os-release-$KERNEL_VERSION

# Format PRETTY_NAME

sed -i “s/^PRETTY_NAME=.*/PRETTY_NAME=\“Ubuntu 26.04 LTS ($KERNEL_VERSION)\”/” /tmp/os-release-$KERNEL_VERSION

# — Build Standard UKI —

echo “Building and signing Standard UKI…”

ukify build \

--stub="/usr/lib/systemd/boot/efi/linuxaa64.efi.stub" \\

--linux="$RAW_KERNEL" \\

--initrd="$INITRD_FILE" \\

--devicetree="$DTB_FILE" \\

--uname="$KERNEL_VERSION" \\

--cmdline="$STD_CMDLINE" \\

--os-release="@/tmp/os-release-$KERNEL_VERSION" \\

--secureboot-private-key="$SB_KEY" \\

--secureboot-certificate="$SB_CRT" \\

--output="$UKI_OUTPUT"

# Cleanup

rm -f “$RAW_KERNEL”

rm -f /tmp/os-release-$KERNEL_VERSION

#rm -rf “$TMP_DTB_DIR”

echo “Successfully generated Standard UKI: $UKI_OUTPUT”

Update from me: I didn’t do much on the yoga 7 dt, just added the dp altmode sound DAIs. Didn’t touch or consider EC. EC needs a bit more research, and a device to test to make changes.

1 Like

As an example: Updated firmware on the Ideapad Slim3x where I had configured an EC driver, after firmware update fan would cease to function. :man_shrugging: Removing the EC node was the interim solution, need to find out what is needed for working EC now.

1 Like

Thanks — that settles it, and I owe you a correction on my gist.

Same BIOS here (NHCN62WW, 12/02/2025), so firmware isn’t the difference.

The white:indicator LED turns out to be a red herring: I checked on my machine and it’s registered by the generic leds-gpio driver from the leds/privacy-led node that’s already in the stock DTB (readlink -f /sys/class/leds/white:indicator → /sys/devices/platform/leds/…), not by the EC driver. It shows up whether or not the EC probes — I’ll fix that verification step in the gist. The EC driver’s actual name is yoga-slim7x-ec, another thing the gist had slightly wrong.

So the check that matters is the one that errored for you: no *-0076 i2c device means the DTB you’re actually booting contains no EC node, the driver never probes, and the EC is never told about suspend — hence the solid LED and the lit keyboard backlight. You can confirm directly against the live tree:

ls /sys/firmware/devicetree/base/soc@0/geniqup@bc0000/i2c@b94000/

On mine that lists embedded-controller@76; I’d bet on yours the directory is missing or has no child. If so, the DTB your UKI script embeds is stale — check it with strings <your.dtb> | grep yoga-slim7x-ec. My guess: the EC node landed on jglathe’s branch after the 7.1.2-jg-1 build you’re running, so the dtb your script extracts predates it.

Once the node is really in your booted DTB, you should get both fixes stacked: EC standby on top of the working deep state — which, going by your numbers, already beats what I get on the Ubuntu Concept kernel.

1 Like

It must be some other issue then because my live tree shows the embedded-controller@76 and childs:

$ ls /sys/firmware/devicetree/base/soc@0/geniqup@bc0000/i2c@b94000

#address-cells’ clocks embedded-controller@76 name power-domains

#size-cells’ compatible interconnect-names phandle reg

clock-frequency dma-names interconnects pinctrl-0 required-opps

clock-names dmas interrupts pinctrl-names status

$ ls /sys/firmware/devicetree/base/soc@0/geniqup@bc0000/i2c@b94000/embedded-controller@76

compatible interrupts-extended name pinctrl-0 pinctrl-names reg

Here’s the my decompiled dtb which is basically the same as your in the gist:

i2c@b94000 {

  		power-domains = <0x3b 0x00>;

  		pinctrl-names = "default";

  		#address-cells = <0x01>;

  		interconnect-names = "qup-core", "qup-config", "qup-memory";

  		pinctrl-0 = <0xa3>;

  		clock-names = "se";

  		interconnects = <0x3e 0x01 0x07 0x3e 0x05 0x07 0x3f 0x03 0x03 0x40 0x19 0x03 0x20 0x00 0x07 0x21 0x01 0x07>;

  		interrupts = <0x00 0x24b 0x04>;

  		clocks = <0x3d 0xae>;

  		#size-cells = <0x00>;

  		clock-frequency = <0x61a80>;

  		dma-names = "tx", "rx";

  		compatible = "qcom,geni-i2c";

  		status = "okay";

  		reg = <0x00 0xb94000 0x00 0x4000>;

  		phandle = <0x25b>;

  		dmas = <0x81 0x00 0x05 0x03 0x81 0x01 0x05 0x03>;

  		required-opps = <0x2e>;

  		embedded-controller@76 {

  			pinctrl-names = "default";

  			pinctrl-0 = <0xa4>;

  			interrupts-extended = <0x60 0x42 0x02>;

  			compatible = "lenovo,yoga-slim7x-ec", "qcom,x1e-it8987-ec";

  			reg = <0x76>;

};

  	};

  	i2c@b80000 {

The 7.1.1-jg-1-qcom-1xe kernel doesn’t have a working webcam on my Slim 7x (no webcam found).

Fairly sure that the normal x1e 7.0 kernel did have this. My webcam has definitely worked in the past.

Are there some camera patches missing?

I can confirm that on the t14s with 7.1.2-jg-1 the webcam doesn’t work as well. The normal camera application stays on initializing

I’m running the “stock” 7.0.0-32-qcom-x1e kernel. Perhaps thats why…
I can’t use 7.1 because I need my webcam working.

New build (based on Ubuntu-Mainline config) incoming where I try to weed out the camss / csiphy deficiencies. Pointers to working trees / patches for certain laptops are appreciated.

1 Like

New build 7.1.3-jg-0 is up. Camera should theoretically work on T14s, A14, Dell. And all UVC equipped models like Ideapad 3,5, Thinkbook 16. My test on T14s was “less errors”, but didn’t have enough time to look for what’s the issue (some library or other?).

Hi, I can’t seem to find the repo for this latest version, have you uploaded it yet? Would like to use it to compile my custom dts so that I can test this version on my Dell latitude 5455

1 Like

It’s up now: GitHub - jglathe/linux_ms_dev_kit at jg/ubuntu-qcom-x1e-7.1.3-jg-0 · GitHub

3 Likes

Hi sorry me again, I seem to be having some issues with this version. The screen won’t turn on after grub selection. I had the same issue with the previous ones too but i didn’t investigate. Compared to the last working kernel version (Linux 7.0.0-32-qcom-x1e) i have these journalctl logs:

Jul 09 17:55:00 kernel: Couldn't find UBWC config data for this platform!
Jul 09 17:55:00 kernel: msm-mdss ae00000.display-subsystem: probe with driver msm-mdss failed with error -22
Jul 09 17:55:00 kernel: qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with supplier a600000.usb for /pmic-glink/connector@0
Jul 09 17:55:00 kernel: qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with supplier 4-0008 for /pmic-glink/connector@0
Jul 09 17:55:00 kernel: qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with supplier 6-0008 for /pmic-glink/connector@1
Jul 09 17:55:00 kernel: qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with supplier a800000.usb for /pmic-glink/connector@1
...
Jul 09 17:55:04 kernel: qcom_q6v5_pas 32300000.remoteproc: timeout waiting for subsystem event response
Jul 09 17:55:06 kernel: qcom,fastrpc 32300000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: failed to create endpoint
Jul 09 17:55:06 kernel: qcom,fastrpc 32300000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: probe with driver qcom,fastrpc failed with error -12
...
Jul 09 17:55:25 kernel: qcom-camss acb7000.isp: failed to get phy csiphy1 0
Jul 09 17:55:25 kernel: qcom-camss acb7000.isp: Failed to init csiphy1 sub-device: -517

Is there anything I can do or should I wait till the next official qcom-x1e kernel version?

Edit:

Strangely booting with the old dtb but your new kernel leads to screen turning on. Probably best to not mix different compiled versions, are there any sort of changes that i need to make to my dts e.g in compatibility, in order for it to work?

1 Like

Yes there is a significant change that needs to be addressed in the dts. The usb block description has been flattened, and the dts needs to reflect that. The old dtb has a different definition but is already compiled (with the includes) and is usable by “any” kernel.
Found your github (I guess), will put a pr for the amended dts.

1 Like

That would be amazing thanks. If you need any info or for me to do any tests don’t hesitate to ask

The more I look the more I have questions. Dell 5455 is a Purwa device, meaning x1p42100. Am I right with this assumption? I added my proposal for the dtb in my tree, maybe you want to try. Please note that I changed the firmware paths (except for sound) to what a Purwa device should have.

The dell latitude 5455 has x1p42100 and x1p64100 versions

I have the x1p64100 version

Then you should just use the 7455 dtb as-is :man_shrugging:

1 Like

unfortunately with 7.1.3-jg-0 there is still no camera on the Slim 7x

1 Like