Current support status for Surface Pro 11 for Business (Intel version)

What is the current support status for Surface Pro 11 for Business (Intel version)?

The #1694 is closed, but Surface Pro 11 (Intel) is not listed in https://github.com/linux-surface/linux-surface/blob/master/README.md.

Also, this device has only question marks in all rows of the https://github.com/linux-surface/linux-surface/wiki/Supported-Devices-and-Features#surface-tablets table.

Why am I asking?

I have this device (Model 2103 — Intel Core Ultra 7 268V CPU, Intel Arc 140V GPU, OLED display, 32GB RAM, 1TB SSD) and the Surface Pro Keyboard (Model 1905) for it.

My goal is to install ChromeOS on it.

I've tried https://github.com/sebanc/linuxloops and https://github.com/sebanc/brunch.

In the first case, an endless black screen with a blinking underscore cursor is displayed.

In the second case (manual method), only the endless black screen even without a cursor is displayed.

According to the description, both projects seem to include linux-surface.

Maybe I'm missing something or doing wrong?

If everything was working more or less fine in #1694, could it have broken due to a firmware update?

I'm very interested in running ChromeOS on this device. Since I have this device on hand, I'm ready to collaborate (by providing any logs and performing tests) with anyone who can help bring the support of Surface Pro 11 for Business (Intel version) to a working state.

@lukas-hetzenecker

@lukas-hetzenecker PTAL. 😉

Hello Team,

please find attached my diagnostics.tar.gz for the "Microsoft Surface Pro for Business 11th Edition with Intel" - or short SP11(I) - with Surface Pro Signature Keyboard (8X8-0004, the one without the Copilot-Key)

I tested with:

Microsoft Surface Firmware: updated to 2025-08-14
Operating System: Fedora Linux 42
- updates current as of 2025-10-03
- 3rd party repos activated
- linux-surface repo added
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.15.3-1.surface.fc42.x86_64
Graphics Platform: Wayland
Processors: 8 × Intel Core Ultra 5 238V
Memory: 32 GiB of RAM

What works for me:

Hardware	Result
Keyboard	✓
Touchpad	✓
Tablet Mode	✓ (yes? Display will switch into vertical portrait mode)
Touchscreen	✓
Pen	? (I don't have one to test)
WiFi	✓
LTE	n/a
Bluetooth	✓
Speakers	❌
Buttons	✓ (the function keys on the type cover are working)
SD Card Reader	n/a
Suspend	? (Switching into standby and wake up in KDE Plasma works. Not sure this is the right suspend mode, but the WiFi has to be powered on again)
Hibernate	? (not tested)
S0ix	? (not tested)
Sensors	?
Battery Status	✓
Performance Modes	?
Cameras	❌

What was pleasantly surprising is, that even with an current vanilla kernel the touchscreen and keyboard cover are working.

What does not work for me:

Kernel 6.16.9 does not boot! The latest working kernel for me is 6.15.3-1.surface or 6.14.0-63.fc42 from the fedora repos. I currently have no clue as of why. I see for a moment the white windows logo on black screen, the fedora logo and for a one second or so the spinning wheel. After that the black screen it is stuck. Please see journalctl_k_6.16.9-1.surface.tar.gz for an output of journalctl -k -b -1.
If I do the shutdown and let it sit, the battery will be drained. The SP11(I) will do the shutdown procedure, but some sort of hibernate is activated. Or maybe it doesn't correctly cut power? Looks like some ACPI tuning is needed? I could also test if the S5 workaround for the 12th Intel works. (Sidenote: If I do a forcefull shutdown by holding down the power button, the drainage issue seems to be gone. But only if I do a forced restart by holding down the power button I will see the systemd-boot boot menu, otherwise it seems to skip it and select default / last chosen one.)
Sound is not working! I have a suspicion that

[    5.276737] sof-audio-pci-intel-lnl 0000:00:1f.3: No SoundWire machine driver found for the ACPI-reported configuration:

is the reason. Maybe some quirk or topology is missing for the SP11(I) so that sof works? Other users with Lunar Lake CPU reported that they needed at least kernel >= 6.14.2, alsa-ucm >= 1.2.14 and sof-firmware >= 2025.01.1 for their machines to work. But that didn't solve it for me (alsa-ucm 1.2.14 & alsa-sof-firmware 2025.05.01). Please let me know how best to proceed. Does the surface-kernel team want to get in touch with SOF? Or should I as owner of an SP11(I) open a bug report?

I hope this information helps to further the support of the SP11(I). Many thanks for the great work you are all doing!

Hello！

I recently purchased Surface Pro 11 (Intel Core Ultra 7 266V).

Model: Surface Pro 11 for Business (Intel)
CPU: Core Ultra 7 266V
BIOS Version: 13.10.143 (2025-03-25)
OS: NixOS 25.05 (kernel 6.12.x, mainline)

During installation and usage on NixOS, I also noticed that several hardware components are not yet supported out of the box.
Touchscreen, Wi-Fi, and Bluetooth all work fine, and Bluetooth audio output functions perfectly.
However, the internal speakers and microphones do not produce sound, and both battery status and keyboard detach events are missing.

I've attached dsdt.dat, dmidecode.txt, and dmesg.txt in case they help with further analysis. hope this information helps !

test.zip

Tested Ubuntu 25.10 and it works, with the mentioned exception of also no audio (kernel 6.17.0-5-generic)

Regarding Kernel 6.14: Maybe I was hit by the log tree bug of btrfs, see Btrfs Sees Urgent Fix Following Recent Reports Of Log Tree Corruption. Reason being Fedora 42 uses btrfs a default filesystem and I did a forcefull power off as shutdown (which could leave the btrfs filesystem "faulty").

Enforcing HDaudio ("legacy") makes it possible to get audio over HDMI. Use the following modprobe configuration:

options snd-intel-dspcfg dsp_driver=1

@AndreGilerson

For the Intel / Lunar Lake SP11, current status from my side (Surface Pro 11 for Business, Core Ultra 7 266V, Arch Linux):

Internal speakers, battery status and keyboard detach all work with @AndreGilerson's patches in #1990. I have been running that daily for two months. The snd-intel-dspcfg dsp_driver=1 HDA fallback mentioned above is not needed with those patches — the SOF/SoundWire path comes up properly, so you get the internal speakers and not just HDMI.

Note that the stock linux-surface package is not enough on its own. On this device the 6.19.8 build loses audio entirely; the patches have to be built in.

The internal microphone is still not working on the 6.18 branch. Details in #1990, and a full before/after for this device in #1876.

@AndreGilerson

The internal speakers are working correctly. I used @AndreGilerson's method.
Thanks for your work. Surface Pro 11 Intel i5 Lunar Lake.

@leihua-dev

Same machine as the original post — Surface Pro 11 for Business, Model 2103,
Core Ultra 7 268V, 32 GB, OLED — so this should be directly comparable rather
than approximately so. Running Ubuntu 26.04, kernel 7.0.0-30, as a daily driver
since July.

Posting because the wiki table still has question marks in every row for this
device, and because the audio situation has changed in a way worth knowing about.

Audio: two patches, and no machine entry

The internal speakers and the microphone work here on the stock
sof-soundwire UCM profile and the shipped topologies — no board quirk, no
soc-acpi-intel-lnl-match.c entry, no local configuration, and no
dsp_driver=1 HDA fallback.

Two patches, sent upstream on 2026-08-30:
https://lore.kernel.org/linux-sound/[email protected]/T/

The firmware describes one physical RT1320 twice on link 0 — SWRA
(_ADR 0x000030025D132000, SDCA class 0) and SWRB (…2001, class 1), same
link, same manufacturer, part and version, same unique_id 0. Only the class-1
descriptor ever enumerates. That ghost consumes an amplifier index, so the real
part is named rt1320-2 and the stock UCM enables switches on a device that is
not there; its endpoints also collide in create_sdw_dailink(), which can fail
the card outright with -EEXIST.

ASoC: rt1320 — run the vendor preset on first hardware init, the way
rt712-sdca and rt722-sdca already do. One line.
soundwire: dmi-quirks — remap the ghost _ADR to zero, keyed on
DMI_PRODUCT_SKU, so sdw_acpi_find_slaves() never creates it.

Relevant to the microphone specifically (@leihua-dev, @AndreGilerson — this
is the item left open in #1876): with the ghost removed and no machine entry
matched, hda_sdw_machine_select() falls through to the generic path, which
loads a dummy base topology and dispatches the SDCA functions itself:

Using function topologies instead intel/sof-ipc4-tplg/sof-lnl-dummy.tplg
loading topology 0: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg
loading topology 1: intel/sof-ipc4-tplg/sof-sdca-mic-id4.tplg
loading topology 2: intel/sof-ipc4-tplg/sof-hdmi-pcm5-id5.tplg

Components: 'HDA:80862820,80860101,00100000  cfg-amp:1
             iec61937-pcm:7,6,5 spk:rt1320 mic:rt1320-1 cfg-mics:1'
arecord -l: card 0: sofsoundwire, device 4: Microphone

That dummy-base-plus-per-function dispatch is what commit ecf74df7 on
v7.0-surface-devel implements by hand. On the generic path you get it for
free, along with cfg-mics:1, whose absence breaks the UCM import on
alsa-ucm-conf 1.2.16.

I have not run @AndreGilerson's branch on this device, so that is their
reports against my measurements rather than one machine tested both ways. I have
offered upstream to do exactly that and will report the result either way.

Status of everything else on this unit

Verified by use or measurement, not by "the driver bound":


Type Cover keyboard, touchpad	work, already upstream (`surface_hid`)
Touchscreen	works (`i2c_hid_acpi`, `MSHW0585`)
Internal speakers + microphone	work — the two patches above
HDMI/DP audio	3 sinks enumerate; never actually listened to, so I will not claim it
GPU Arc 140V	works. Vulkan 1.4.335 conformant, Mesa 26.0.8, vkmark 3635 / glmark2 3911 at 2880×1920. Windows games run under Proton
Suspend (s2idle) + lid wake	works. 98 % S0ix over an 8.45 h sleep, ≈134 mWh/h
Battery, charger, thermal (68 zones), fan	work
Brightness, accelerometer/auto-rotation, ALS, gyro	work
Wi-Fi 7 BE201	works out of the box
NPU	works out of the box — `intel_vpu`, `/dev/accel/accel0`. Rarely mentioned, so worth stating
TPM 2.0, Secure Boot	work. Secure Boot is on here with `lockdown=integrity` and `module.sig_enforce=Y`; locally built modules load because they are signed with an enrolled MOK
External DP over USB-C, Thunderbolt/USB4	work
Stylus	axes are declared; no pen to test with

Not working


Cameras ×3	dead. `int3472` does not handle GPIO type `0x08`, so the sensor is never powered and `ov13858` fails `-EIO` with an empty media graph. Half of it is fixed by @jakobbergjespersen's POWER1 patch, which I tested here — the warning goes away and `dvdd` registers, but the camera stays dead because `ov13858` never requests the supplies. IPU7 itself is healthy
NFC	present (`1FC93002`, NXP, I²C 0x28), adding the id makes `nxp-nci_i2c` bind and register `nfc0`, but the chip NAKs every read and write. Five hypotheses eliminated with evidence. No Surface has ever described NFC power in ACPI, and nobody has had Surface NFC working under Linux. Do not submit an `acpi_device_id` patch — it binds and achieves nothing
Volume/power buttons	`soc_button_array` attaches on its own on 13 of 40 boots, measured. When it fails it logs nothing at all. Reported: https://lore.kernel.org/linux-input/[email protected]/T/. A `systemd` unit that binds it by hand is the workaround
Bluetooth, two separate faults	(a) aborts system suspend with `error -16` — an upstream fix exists and has waited unreviewed since May; I reproduced it and added `Tested-by`: https://lore.kernel.org/linux-bluetooth/[email protected]/T/. (b) controller comes up dead with `Unsupported cnvi 0x00000000` on 16 of 50 boots — not cold-boot-specific, 12 of those followed a warm reboot. Reloading the module always recovers it
Keyboard backlight	the key emits HID Consumer usage `0x000c0515`, outside the standard block, so it arrives as `KEY_UNKNOWN`; an hwdb entry maps it. The backlight itself is driven by the keyboard's own controller — no LED device, level not readable

ACPI dumps

There is no Intel SP11 dump in linux-surface/acpidumps, only the ARM one.
35 tables from this machine: linux-surface/acpidumps#34

Caveats worth stating

Nothing above is merged. The audio patches are in review, the buttons and
Bluetooth reports have had no reply, and this machine runs locally built,
locally signed modules. Three of the faults above are covered by workaround
services rather than fixed.

Happy to run tests on this unit — it is a daily driver, but experiments are
fine.

@eidos-case

@eidos-case — thanks for the writeup, and for keying the remap on DMI_PRODUCT_SKU: it matches my unit exactly (Surface_Pro_11th_Edition_With_Intel_For_Business_2103, Core Ultra 7 266V, BIOS 17.100.143).

Short version of the comparison you offered to run — I did it here instead, on the machine from #1876:

The microphone works now. arecord -l → card 0, device 4: Microphone, real signal (4 s capture, peak −8.7 dBFS). Same per-function dispatch your log shows, sof-sdca-mic-id4.tplg included.
The ghost is real and your patch kills it. Before: both _ADRs present, …:00 permanently UNATTACHED, and ACPI enumerating SmartMic/SmartAmp twice. After: one pair only.
But on v6.18-surface-devel the fix was to complete the machine entry, not remove it — that branch already has one, in a pre-ecf74df7 form, and its generic fallback never builds a Capture-SmartMic dailink at all.
One trap worth knowing: sof-sdca-1amp-dummy.tplg exists in no sof-bin release, and sof_test_topology_file() runs unconditionally before probe — so that name in a machine entry means no sound card at all, speakers included.

Details, logs and the exact five edits are in my reply on #1876: #1876 (comment)

@AndreGilerson

Camera and biometrics update for this machine, since the status above is now out
of date on both.

Full writeup with everything inlined: #2260.

All three cameras work, and face login works. The infrared sensor images
correctly and its illuminator fires — GPIO 1, established by blinking each pin
an index-many times for a person to count and then confirmed photometrically.
Howdy unlocks the screen through gdm-password, with four enrolled models
giving certainty 2.7 against a 3.5 threshold; a different person sitting in
front of the camera measures 6.5 and is refused.

Patches sent since the last update here:

ov13858 power sequencing, v3 after review —
https://patch.msgid.link/[email protected]
ov13858 analogue gain cap; the control is advertised to 0x1fff and is honest
only to 0x7ff — https://patch.msgid.link/[email protected]
libcamera sensor helper for the imx681, without which the AGC reads the raw
gain code as a gain and under-exposes by 4.5x — sent to libcamera-devel
the vendor's full INT3472 GPIO type table, where four values disagree with
ours — sent to platform-driver-x86 as a question, not a patch

Still not working: NFC. The chip NAKs everything and five hypotheses are
eliminated with evidence; the only untried lead is a Windows ETW capture.

For the colour cameras specifically, @AndreGilerson's #1990 carries a full IPU7
hardware-ISP setup and is the better route for image quality. #2260 is written
as a companion to it, not a replacement.

@AndreGilerson

Closing a loose end from my status comment above, where I said I had not run
@AndreGilerson's branch on this device and would report the comparison result
either way. I ran it on 30 August and reported it upstream the same
day,
but never brought the result back here, which is where I promised it.

Method, and why it is not quite what I promised. Booting his kernel would have
changed several thousand things at once, so instead: the same running kernel
(7.0.0-30-generic), the same firmware, the same userspace, only the audio
modules swapped — built from the Ubuntu source tree on the machine, signed
with the enrolled MOK, distro modules parked beside them.

A — mine: dmi-quirks removes the ghost _ADR, rt1320 preset fix
B — his: the machine entry from ecf74df7982d, my two patches removed

Two of his four hunks are already upstream. His commit is from May; against
shipping 7.0, the soc_sdw_utils.c MIC DAI is already there and more complete,
and the sof_sdw.c name forcing is obsolete because the append_dai_type
branch is gone. So part of what makes his branch work for people today is not
his patch — it is upstream having since done the same thing. That is the direct
answer to the microphone question: the mic DAI is in stock 7.0, which is why
the generic path finds the microphone with no machine entry at all.

With class_id matching added, both land in the same place. Same function
topologies (1amp-id2, mic-id4, hdmi-pcm5-id5), same 4 playback / 1 capture,
same rt1320-1 prefix, zero probe errors either way. On this machine both work.

The machine entry alone does not match, and fails hard. Forward-porting only
his entry, the kernel sees two identical peripherals — the ghost and the real
amplifier, indistinguishable without comparing class_id — rejects the entry,
and falls back to the generic path with the ghost still enumerated:

sysfs: cannot create duplicate filename '.../sof_sdw/SDW0-Capture-SmartMic'
sof_sdw sof_sdw: probe with driver sof_sdw failed with error -12

No card at all. That is reproducible from a clean boot, and it independently
confirms the correction my v2 made in public after my v1 cover letter had called
that failure undemonstrable.

So the comparison does not decide "which works" — both do. It decides what each
costs the rest of the kernel: his approach needs class_id added to generic
SoundWire matching before his entry can match at all, which is a change to code
every SoundWire machine goes through.

@leihua-dev — you had effectively already run this on #1876 and your correction
there was right; this is the same conclusion from the other direction, posted
here because this is where I said it would go.

Navigation Menu

Repository navigation

Current support status for Surface Pro 11 for Business (Intel version) #1852

Audio: two patches, and no machine entry

Status of everything else on this unit

Not working

ACPI dumps

Caveats worth stating

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Current support status for Surface Pro 11 for Business (Intel version) #1852

Description

Activity

FluorescentHallucinogen commented on Sep 9, 2025

Adurol commented on Oct 4, 2025

leihua-dev commented on Oct 15, 2025

Adurol commented on Oct 17, 2025

Adurol commented on Jul 12, 2026

leihua-dev commented on Jul 31, 2026

estebanrobledorodriguez commented on Aug 22, 2026

eidos-case commented on Aug 30, 2026

Audio: two patches, and no machine entry

Status of everything else on this unit

Not working

ACPI dumps

Caveats worth stating

leihua-dev commented on Aug 30, 2026

eidos-case commented on Aug 31, 2026

eidos-case commented on Sep 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions