Surface Pro 11 (Intel, Lunar Lake) — status, and how to live with it today

Surface Pro 11 comes in two versions. The ARM one is widely discussed; this is
about the Intel one, which behaves quite differently.

Everything below is from one machine: Surface Pro for Business 11th Edition with
Intel, SKU Surface_Pro_11th_Edition_With_Intel_For_Business_2103, Core Ultra 7
268V, UEFI 17.105.143 (17.100.143 until the end of August), Ubuntu 26.04. Most
of it was measured on kernel 7.0.0-30, which Ubuntu has since replaced; the
audio results below were taken again on 7.0.0-34 on 2026-09-25 and are
unchanged. Where a claim rests on a second machine, it says so.

Updated 2026-10-08. A fix for the infrared camera went to linux-media: the
IPU7 wrote frames without snooping the CPU's cache, so a program reading them
got rows of an older frame. The buttons fix is in seven stable trees now, still
not 7.0. The Bluetooth-after-boot workaround has moved here from #2267. One
correction: its race was put down to Ubuntu's own patches, but what in Ubuntu's
kernel brings it in was never narrowed down, and the 7.0.y stable updates under
those patches are among the candidates.

One thing learned the hard way and worth passing on: if you build any of these
patches into your own modules, a kernel upgrade silently reverts them. The
patched modules live in /lib/modules/<version>/, and a new kernel ships
pristine copies, so the symptom comes back looking like a regression in the new
kernel. It is not. Rebuild for the new version before blaming it.

I will keep this updated as patches land. Corrections welcome — several things
here were wrong the first time and were fixed because people said so.

Short version

Out of the box you get a working tablet with no sound and no cameras. Two
fixes are in mainline and six more are accepted by their maintainers; four
are on mailing lists, and the infrared camera's driver is not on one yet. The
cameras additionally need tuning data that cannot come from upstream at all.
None of it is hard once you know what is missing, which is the point of this
page.

Works with a stock kernel, nothing added

Display and backlight, touch, the keyboard cover and its trackpad, Wi-Fi and
Bluetooth as devices, battery and charging, thermals. Not tested: the pen,
because there is none here.

Hardware video decode works too, but needs Ubuntu's intel-media-va-driver,
which was not installed here. With it, H.264, HEVC (also 10-bit), VP9 and AV1
all decode on the GPU's video engine through VA-API.

Suspend works, and reasonably well: S0ix residency measured between 70 % and
94 % depending on what is running. Lid close and open both work, with one
caveat below.

Needs a kernel patch

The board describes one amplifier twice

Worth understanding, because it explains the most confusing failure. There is
one physical RT1320 on SoundWire link 0, described by two _ADR entries that
differ only in SDCA class id. Only the class-1 entry ever attaches. The ghost
consumes an amplifier index, so the real part is named rt1320-2 and the stock
UCM profile drives switches on a device that is not there; and its endpoints
reach create_sdw_dailink(), which builds DAI link names from link id and
function type alone, so its SmartMic collides with the real one:

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

aplay -l then reports zero cards. Removing the ghost at enumeration fixes both
symptoms at once. Confirmed independently on a second Surface Pro 11 with a
different BIOS.

Re-measured on 7.0.0-34 on 2026-09-25, with the quirk and the rt1320 preset
built in and nothing else — no machine entry, stock UCM:

With the quirk there is one SoundWire peripheral, sdw:0:0:025d:1320:01,
status=Attached. The microphone then produces real signal rather than merely
enumerating: a four-second capture from hw:0,4 peaks at 4568 of 32767
(−17.1 dBFS), RMS 846.5, across 6391 distinct sample values. A dead or stuck
channel gives one. speaker-test clocks a 1 kHz sine through the playback path
without error.

So the microphone needs no patch of its own. The quirk is the whole of it.

The buttons are fixed in mainline, but not for 7.0

In 7.0 the driver deliberately discards -EPROBE_DEFER when looking up button
GPIOs, because some Intel platforms declare virtual GPIOs that never
materialise and deferring on those would hang the probe forever. Here the GPIO
controller (INTC105D, five gpiochips under pinctrl-intel-platform) simply
has not finished probing yet, and the buttons are dropped silently — nothing is
logged at all, on any level, because every button is skipped and n_buttons
stays 0.

Distinguishing "virtual GPIO that will never appear" from "controller not ready
yet" is the actual problem, and I did not want to guess at it. A softdep does
not help: the race is against the asynchronous probe of the individual
INTC105D:0N devices, not module load order. Tested, 2 successes in 5 boots,
same as without.

Hans de Goede, who knows the subsystem, drew the line: his fix waits for the
GPIO controller everywhere except on Bay Trail and Cherry Trail, where the
virtual GPIOs are. It is in mainline from 7.3-rc4 and in seven stable trees,
none of them 7.0, which Ubuntu's kernel is built from. Until yours has
it, a service that binds the driver after boot works reliably — 25 unbind/bind
cycles, 25 successes.

Cameras need more than a kernel

Three cameras: rear ov13858, front imx681, infrared vd55g0 for face login.

Only the rear one has an in-tree driver. The front and infrared cameras have no
driver in any released kernel — those are the imx681 and vd55g0 rows in the
table above, and until they land no amount of userspace helps. Even with all of
it, the pictures are unusable without tuning data, which is per-sensor and
per-board and does not come from upstream.

Tuning files, a Howdy plugin for face login through the IR camera, and the
traps involved are in #2267.

The front camera additionally needs a CameraSensorHelper in libcamera, without
which it is under-exposed by about 4.5x. Sent to libcamera-devel 2026-08-31,
and held at our request until the kernel driver lands: a helper should not
come ahead of its driver.

Workarounds worth having for now

These are what this machine actually runs. They are small, and each can go
once your kernel no longer needs it; only the buttons one has a fix upstream.

• buttons — a service that binds soc_button_array after boot.
• Bluetooth after boot — a service that reloads btintel_pcie when a
  race in the firmware download leaves the controller dead at boot. The race
  hit about one boot in three on Ubuntu's 7.0.0-34 here, and none of 41 on
  mainline v7.0 built with Ubuntu's configuration. What in Ubuntu's kernel
  brings it in was never narrowed down; the 7.0.y stable updates under it are
  among the candidates, so other 7.0 kernels may have it too. Ubuntu's
  7.0.0-38 still has it: 2 boots of 41 here. It is reported in
  Launchpad bug 2161900.
  If you installed the service before 2026-09-29, replace it: that version
  could kill the controller itself. The service is below.
• lid wake — a service that arms the SAM transport so opening the cover
  wakes the machine.

/usr/local/sbin/sp11-bt-recover
/etc/systemd/system/sp11-bt-recover.service

chmod +x /usr/local/sbin/sp11-bt-recover
systemctl daemon-reload
systemctl enable sp11-bt-recover.service

#!/bin/sh
# btintel_pcie sometimes brings the controller up dead at boot:
#   Bluetooth: hciN: Unsupported cnvi 0x00000000
#   Bluetooth: hciN: Controller in error state
# leaving the adapter DOWN with BD address 00:00:00:00:00:00. A mailbox
# interrupt arrives during the firmware download before the driver is waiting
# for it. Reloading the module recovers it, but only once the firmware setup
# has given up.
# Poll rather than sleeping a flat 20 s. The controller settles in a couple of
# seconds when it is healthy, and this used to add the full 20 s to every boot.
DEV=/sys/bus/pci/devices/0000:00:14.7
MOD=/sys/module/btintel_pcie
[ -d "$DEV" ] || exit 0

# The first BD address that is not all zeros, or nothing.
real_addr() {
	hciconfig 2>/dev/null | grep -oE "BD Address: [0-9A-F:]+" | cut -d' ' -f3 |
		grep -m1 -v "^00:00:00:00:00:00$"
}

# The firmware setup runs after the probe has returned, at 00:00:00:00:00:00
# throughout. A failing one takes about 8 s to give up, and one saved by the
# driver's own retry about 5 s. Unloading in the middle of it frees the
# interrupts under it, and the probe of the next load then fails with -62 and
# leaves no adapter at all: the previous version, which reloaded on the first
# zero address, lost every race boot that way. So a zero address is a verdict
# only after 15 s. No driver bound means a probe failed and nothing is
# running, so reload at once, as soon as the module's init has returned
# (modprobe -r refuses it before).
why=
i=0; noaddr=0
while [ $i -lt 60 ]; do
	[ -n "$(real_addr)" ] && exit 0                   # healthy, nothing to do
	if [ "$(cat "$MOD/initstate" 2>/dev/null)" = live ]; then
		[ -e "$DEV/driver" ] || { why="no driver bound"; break; }
		[ $noaddr -ge 15 ] && { why="no address for 15 s"; break; }
		noaddr=$((noaddr+1))
	fi
	sleep 1; i=$((i+1))
done
if [ -z "$why" ]; then
	state=$(cat "$MOD/initstate" 2>/dev/null)
	if [ -z "$state" ]; then
		logger -t sp11-bt-recover "btintel_pcie is not loaded, leaving it alone"
		exit 0
	fi
	logger -t sp11-bt-recover "btintel_pcie still '$state' after 60 s, its init has not returned; not reloading"
	exit 1
fi

# Stop bluetoothd, unload, check that the unload took, load again and wait for
# an address. Firmware download takes a few seconds; wait for a real address
# before logging, otherwise the log reports the pre-recovery state and looks
# like a failure. The 15 s also outlasts a failing setup, so a second unload
# does not land in the middle of one.
reload() {
	systemctl stop bluetooth
	# btintel goes too, when nothing else uses it.
	err=$(modprobe -r btintel_pcie 2>&1)
	if lsmod | grep -q "^btintel_pcie "; then
		logger -t sp11-bt-recover "unload failed, btintel_pcie is still loaded: ${err:-modprobe -r gave no reason}"
		systemctl start bluetooth
		return 1
	fi
	[ -z "$err" ] || logger -t sp11-bt-recover "modprobe -r btintel_pcie: $err"
	sleep 2
	modprobe btintel_pcie
	systemctl start bluetooth
	i=0
	while [ $i -lt 15 ]; do
		addr=$(real_addr)
		[ -n "$addr" ] && return 0
		sleep 1; i=$((i+1))
	done
	return 1
}

logger -t sp11-bt-recover "controller came up dead, reloading btintel_pcie ($why; waited $i s)"
if reload; then
	logger -t sp11-bt-recover "recovered: $addr"
	exit 0
fi
# The race can strike the reload too. Once more, then give up and say so.
logger -t sp11-bt-recover "first reload did not recover the controller, trying once more"
if reload; then
	logger -t sp11-bt-recover "recovered on the second reload: $addr"
	exit 0
fi
logger -t sp11-bt-recover "reload did not recover the controller, twice"
exit 1

[Unit]
Description=Recover the Bluetooth controller if it comes up dead
After=bluetooth.service
Wants=bluetooth.service

[Service]
# Type=simple, not oneshot: this gates nothing, and as a oneshot systemd made
# multi-user.target wait for it, putting its whole check on the boot path.
Type=simple
ExecStart=/usr/local/sbin/sp11-bt-recover

[Install]
WantedBy=multi-user.target

An earlier version of this page also listed a sleep hook that unloads
btintel_pcie around suspend. It never ran here: systemd reads sleep hooks
only from /usr/lib/systemd/system-sleep/, and it sat in /etc. Every
suspend on this machine has used the driver's own path, 30 in a row clean
after the first day, so it is gone from the list.

Keep Secure Boot on

If you build patched modules, sign them with a Machine Owner Key rather than
turning Secure Boot off. On this machine the Windows Hello PIN is sealed to TPM
PCR 7, which measures Secure Boot state: turning it off invalidates the PIN on
the Windows side, and Windows is still the only way to apply firmware bundles.

This is not exotic — MOK is the same mechanism Ubuntu already uses for nvidia
and virtualbox. It does not touch the boot chain: the distribution kernel stays
signed by Canonical, shim by Microsoft's third-party CA. Only your own modules
need your key.

Known unsolved

• The infrared illuminator never fires, so face login fails in the dark. The
  driver has to be told which sensor pin drives it, and ACPI does not say.
  Told by a local test patch, it lights, but only while the exposure is under
  about 70 % of the frame; in the dark the sensor's auto exposure goes past
  that and the picture stays black.
• The rear camera is about 24 % darker than the same scene under Windows, which
  drives a hardware ISP that Linux does not.
• libcamera's soft ISP has no highlight rolloff, so bright windows clip flat.
• NFC answers nothing at all. Five hypotheses eliminated; closed deliberately
  rather than left open.

Upstream threads

• audio: https://lore.kernel.org/linux-sound/[email protected]/T/
• ov13858 power: https://lore.kernel.org/linux-media/[email protected]/T/
• ov13858 gain: https://lore.kernel.org/linux-media/[email protected]/T/
• ov13858 flips: https://lore.kernel.org/linux-media/[email protected]/T/
• imx681: https://lore.kernel.org/linux-media/[email protected]/T/
• IPU7 snoop: https://lore.kernel.org/linux-media/[email protected]/T/
• int3472 GPIO types: https://lore.kernel.org/platform-driver-x86/[email protected]/T/
• buttons: https://lore.kernel.org/linux-input/[email protected]/T/
• btintel suspend: https://lore.kernel.org/linux-bluetooth/[email protected]/T/

ACPI dumps for this machine are in
linux-surface/acpidumps#34,
not merged yet.