[Data] Surface Pro 11 (Intel Core Ultra 7 266V, Business Model) - Partial support, mic still missing

Device Information:
• Model: Surface Pro 11 for Business (Intel)
• CPU: Intel Core Ultra 7 266V (Lunar Lake)
• BIOS Version: 13.10.143 (2025-03-25)
• OS: NixOS 25.05 (Kernel 6.12.x mainline)
• Accessories: No original Type Cover keyboard or Surface Pen purchased; a wired USB keyboard works normally.

⸻

Summary:

NixOS 25.05 runs mostly fine on the Surface Pro 11 (Lunar Lake), but several hardware components are not yet supported out of the box.

Working:
• Touchscreen
• Wi-Fi
• Bluetooth
• Bluetooth audio output
• Wired USB keyboard (works as expected)
• Battery status detected

Not working / missing features:
• Internal speakers produce no sound
• Built-in microphones not functional
• Short press of the power button does nothing (no suspend event)
• Camera not detected（hardware same as SP10）

⸻

Attached Files:
I’ve included the following data files for further analysis:
• dsdt.dat
• dmidecode.txt
• dmesg.txt

All three are collected from the NixOS installation environment.

test.zip

If any additional logs or tests (ACPI, EC, audio codec dump, etc.) are useful, I’m happy to provide them.

I am not sure how easy it will be to get cameras working, but I guess the first step is to figure out the sensors.
While you are booted into windows you can check which camera sensors it has:
what it looks like for sp10:
#1354 (reply in thread)

camera list for surface devices: https://github.com/linux-surface/linux-surface/wiki/Camera-Support

Thanks！I checked the hardware, and the Surface Pro 11 (Intel) uses the same camera sensors as the Surface Pro 10 (IMX681 + OV13858 + VD55G0).both still rely on the IPU6 pipeline, which is not supported yet.So it seems the SP11 cameras will also not work on Linux at this point.

Anybody managed to get sound working on Surface 11 Pro Business?

Anybody managed to get sound working on Surface 11 Pro Business?

not that i know of, i gave up and just use bluetooth.

I wanted to ask if you considered starting a gofundme or similar to continue work - I know it's a hobby project with a small team. I would be willing to contribute a couple hundred $$$ for SP11 support, which of course is not a lot in itself, but I am sure there are others in the same boat.

I am also very interested in support for Intel SP11 and would be willing to contribute to its development (particularly to get to the point where audio is supported)

@noresttherein

@noresttherein, @wokawoka I have enabled both speakers and the mic in #1990. Id appreciate if you could test it on your setups as well.

I am also quite close on enabling the cameras i believe, at least i have image output from the rear facing camera, but the front IMX681 is still giving me some trouble. But i do see both cameras with libcamera, and have the voltage regulators and clocks figured out. Just the init sequence is giving me some trouble. But i figure i can get it working in the next weeks.

I'll gladly give it a shot. The pull request hasn't been merged (makes sense if you request external testing), so I guess I can't get it officially. Any chance for a deb/debs? I haven't installed a kernel from sources, so would prefer an idiot proof process to make sure I don't mess up something on my end. I had/plan to have Zorin on my Surface. Note however that I experienced unrecognized wifi adapter in 6.17.1-surface-2 per #1936. While technically I can test the sound even if wifi doesn't work, it will make things a bit harder for me, as I am a moron without the internet.

I have build deb packages with an updated version of the kernel that you could test: https://github.com/AndreGilerson/linux-surface/releases/tag/6.17.13_mic_cam.

I am not familiar with Zorin, but from what i see on the website it should support it. Otherwise ubuntu 25.10 should do the trick, at least thats what I am developing my fixes on.

Please check functionality of speakers and the camera, and if you can the cameras as well. I have both the rear and front sensor working with that kernel version. libcamera is required to run it. Please use the newest version from the repo, as the ones in the package repositories could be older and without ipu7 support. After installation of libcamera, with cam -l both cameras should show up and qcam should be able to view a stream from both. Please note that the image quality will be terrible atm, because the image sensor processing pipeline is not fully functional. But the colors should at least be the correct channels. Furthermore, you will not be able to use the cameras in other applications atm, because the correct loopback device is not yet configured.

Sadly I cannot reproduce the Wifi problems mentioned in #1936 with my ubuntu 25.10 setup, so maybe the newer kernel version fixes that.

If there are any problems please provide dmesg and journalctl output.

EDIT: The kernel i build is is not signed, so you might need to disable secure boot.

@AndreGilerson

@AndreGilerson
I have a SF11 Pro w Intel 268V. Currently on Mint 22.3 Cinnamon , Kernel 6.18.7-surface-1
WiFi is working,however all kinds of other problems, like not waking up. Bottom line not usable for daily work
Having said this, I am game to install any distro and test/report back - just let me know

@oskaratk

@oskaratk Please try building the kernel with my patches: https://github.com/AndreGilerson/linux-surface, and provide feedback on stuff that is not working. As mentioned above, my patches should enable both audio, mic and cameras. Beyond that I have not pushed any changes yet. These patches are also quite safe, in the sense that they should not brick the system, or at least I was running them for quite a while without major issues, but YMMV.

From my experience with Ubuntu 25.10 I can confirm that sleep behaviour is a bit flaky atm. I am working on it, and have some fixes already. However I was trying a big patch to the device tree and bricked my surface. It is currently being reflashed by Microsoft, which is why I have not continued my work during the last few days. But as mentioned, my github repo does not yet contain these changes, so it should be safe.

As soon as my Surface returns I will continue the development. I want to move off Windows as soon as possible, so I am currently actively working on fixing any issues. So any support with reporting changes etc. is appreciated.

Has anyone tried installing ChromeOS on this device? I tried back in September 2025 using projects https://github.com/sebanc/linuxloops and https://github.com/sebanc/brunch, but unfortunately without success. See #1852.

Maybe I’m doing something wrong? Could someone please try to get ChromeOS running on this device?

Actually, ChromeOS on Surface Pro 11 (Intel) is my dream, since ChromeOS is quite well adapted for tablets with touchscreens.

@AndreGilerson

@AndreGilerson thank you for your effort! I've tried compiling a kernel with your patches on Fedora Linux, however I didn't suceed yet. I've particularly had difficulties as I'm using a 6.19 kernel currently and I found its not that easy compiling an older kernel on fedora.
I might try again if I find some time.

However for me the poweroff/suspend issues were solved (i guess), by adding the kernel parameters from the reddit post referenced in #1864 (maybe inspecting this could also help developping a proper fix, but unfortunately I'm not experienced in this).

I'm now daily-driving Linux (firstly EndeavourOS, now Fedora 43 with stock kernel) on my SP11 (I) since half a year and now that the power management is working the biggest issues remaining are sound and cameras.

@AndreGilerson

@AndreGilerson

Please try building the kernel with my patches: https://github.com/AndreGilerson/linux-surface,

on the side: installed Zorin first today, plus the "official" surface kernel. A shutdown/power off from the GUI does not turn off the machine. Battery went from 100% to 40% within a few hours.

Then installed Ubuntu 25.10-desktop-amd64 (ssd wiped)

safe boot off now
downloaded your 3 .deb packages and installed those using gdebi
update-grub

machine still running :-)

However, I do not see a change re camera or speaker.
Did I miss something? User error ?

Somehow the front camera disappeared again (and a reboot didn't fix it):

cam -l
[0:00:57.318322264] [5926]  INFO Camera camera_manager.cpp:330 libcamera v0.5.2
[0:00:57.338581892] [5930]  WARN CameraSensor camera_sensor_legacy.cpp:501 'ov13858 1-0010': No sensor delays found in static properties. Assuming unverified defaults.
[0:00:57.343077221] [5930]  WARN IPAProxy ipa_proxy.cpp:177 Configuration file 'ov13858.yaml' not found for IPA module 'simple', falling back to 'uncalibrated.yaml'
[0:00:57.356343419] [5931]  INFO IPAProxySoftWorker soft_ipa_proxy_worker.cpp:448 Starting worker for IPA module /usr/lib64/libcamera/ipa/ipa_soft_simple.so with IPC fd = 18
[0:00:57.357617665] [5930]  INFO Camera camera_manager.cpp:220 Adding camera '\_SB_.PC00.I2C3.CAMR' for pipeline handler simple
Available cameras:
1: Internal back camera (\_SB_.PC00.I2C3.CAMR)

It's somehow strange, the front camera did appear at some point (without changing anything as far as I know) and now it disappeared again.

Now it seems to be working again:

cam -l
[2:13:37.782306394] [29056]  INFO Camera camera_manager.cpp:330 libcamera v0.5.2
[2:13:37.800152432] [29060]  WARN CameraSensor camera_sensor_legacy.cpp:501 'ov13858 1-0010': No sensor delays found in static properties. Assuming unverified defaults.
[2:13:37.800346498] [29060]  WARN CameraSensorProperties camera_sensor_properties.cpp:484 No static properties available for 'imx681'
[2:13:37.800360459] [29060]  WARN CameraSensorProperties camera_sensor_properties.cpp:486 Please consider updating the camera sensor properties database
[2:13:37.800367541] [29060]  WARN CameraSensor camera_sensor_legacy.cpp:501 'imx681 3-0010': No sensor delays found in static properties. Assuming unverified defaults.
[2:13:37.803611348] [29060]  WARN IPAProxy ipa_proxy.cpp:177 Configuration file 'ov13858.yaml' not found for IPA module 'simple', falling back to 'uncalibrated.yaml'
[2:13:37.816713420] [29061]  INFO IPAProxySoftWorker soft_ipa_proxy_worker.cpp:448 Starting worker for IPA module /usr/lib64/libcamera/ipa/ipa_soft_simple.so with IPC fd = 22
[2:13:37.817947466] [29060]  INFO Camera camera_manager.cpp:220 Adding camera '\_SB_.PC00.I2C3.CAMR' for pipeline handler simple
[2:13:37.820385902] [29060]  WARN IPAProxy ipa_proxy.cpp:177 Configuration file 'imx681.yaml' not found for IPA module 'simple', falling back to 'uncalibrated.yaml'
[2:13:37.840141511] [29065]  INFO IPAProxySoftWorker soft_ipa_proxy_worker.cpp:448 Starting worker for IPA module /usr/lib64/libcamera/ipa/ipa_soft_simple.so with IPC fd = 27
[2:13:37.841488293] [29065]  WARN IPASoft soft_simple.cpp:103 IPASoft: Failed to create camera sensor helper for imx681
[2:13:37.841994337] [29060]  INFO Camera camera_manager.cpp:220 Adding camera '\_SB_.PC00.I2C5.CAMF' for pipeline handler simple
Available cameras:
1: Internal back camera (\_SB_.PC00.I2C3.CAMR)
2: Internal front camera (\_SB_.PC00.I2C5.CAMF)

Ok so in the past few days I have implemented a few additional scripts that are not directly related to the kernel, but automates some of the additional config required:

Audio contrib module installs additional eq parameters and configures other audio libraries
Camera module clones and installs ipu7 drivers, and possible allows the user to extract additional camera parameters from the Microsoft firmware
Suspend module configures the system for proper suspend, and allows the user to enable hibernate
Touchpad module configures a few fixed for the touchpad of the keyboard cover

The install scripts were developed on Ubuntu so I am sure whether they will work on other systems. I would appreciate some assistance in testing them, especially on other distros. So it would be great if everybody here can pull my latest changes and provide some additional results: https://github.com/AndreGilerson/linux-surface

@AndreGilerson

@AndreGilerson
I'll be happy to test.
My SF11 is not in production use yet, so I can do either of

remove the manual installed patches
fresh clean install
and then run the scripts
(all on Mint, if you don't mind)

@AndreGilerson

@AndreGilerson
Also happy to help - running Arch (CachyOS) on SP11 but running these scripts does not appear fix audio/sleep/etc. I have custom compiled the kernel for 6.19.6 with the patches and run the scripts, but still no audio or sleep works. If there is any output that would be useful please let me know. Thanks for all your contributions, seems to be close...

@dankasfuk

@dankasfuk
https://github.com/AndreGilerson/linux-surface/tree/master/contrib

Ok, some progress. I was able to successfully recompile the CachyOS kernel (6.19.6.1) with the audio patch so audio is now working as expected. The other patches give offset errors when attempting to compile (e.g., Hunk #2 FAILED at 1816.) As before, if there is any way I can help troubleshoot please let me know. Great just to have sound :-D

Ok some I have moved off my original Ubuntu 25.10 install with the 6.17 version of the kernel, because at least for me i had implemented most of the features that stopped me from using linux on the surface. I have now installed my nixos config on the surface, with part of the patches because, this requires some nix specific setup and fixing which i have not yet completed. Part of this will require me to also port the patches to newer versions of the kernel.

Also this also means that i will no longer be able to check the functioning of the contrib install scripts that I provided for my changes. So It would be actually great if some of you could check those and provide feedback, especially on other distros besides ubuntu 25.10.

@AndreGilerson

@AndreGilerson

ok - finally I've got some time and motivation to test.
I intend to use the latest Zorin pro, so I am on a pretty up-to-date kernel

Would be great if you could give a bit guidance what and which sequence to install after the initial OS install.
That way we are not ending up with something nobody knows how it happend

Thanks
Oskar

@AndreGilerson

@AndreGilerson I didn't have time to test things in the last few weeks, but maybe I will have some time in the next few weeks.
For now I am running your kernel with the patches until 0018 and this is working really good. The sound is working reliably, both over the internal speakers and also with sound over HDMI (which wasn't working before).

I'd however like to upgrade to 6.18 or 6.19. Do you think it will be possible to adapt the patches to these kernel versions?

Fix RT1320 mic not appearing in HiFi profile see issue linux-surface#…

@AndreGilerson

Status update from the original reporter, since quite a lot has changed since October and the title of this issue is now misleading.

Device: Surface Pro 11 for Business (Intel, Core Ultra 7 266V), Arch Linux. Kernel built from the HEAD of @AndreGilerson's v6.18-surface-devel branch (8ab9347b), with his audio and suspend contrib packages installed.

Of the four things I originally reported as broken:

	Oct 2025	Now
Internal speakers	not working	working
Internal microphone	not working	still not working
Battery status	missing	working (`BAT1` reports capacity and status, `ADP1` present)
Keyboard detach event	missing	working (`Microsoft Surface POS Tablet Mode Switch`, `SW_TABLET_MODE`)

To be explicit for anyone finding this issue later: all of that comes from @AndreGilerson's patches in #1990, not from the official linux-surface kernel. Installing the stock linux-surface package is not enough, and on this device the 6.19.8 build actually loses audio entirely.

The microphone is the one item left from my original report. I posted the details in #1990. Short version: the mic DAI link is never created on the 6.18 branch, because the monolithic sof-sdca-1amp-id2.tplg base topology is loaded and the SmartMic SDCA function is dropped. The card ends up with playback PCMs only. That is already fixed on v7.0-surface-devel (commit ecf74df7, dummy base topology plus per-function dispatch) but has not been backported to 6.18.

Cameras: the drivers are in the branch, but I have not actually tested capture, so I can't report either way on those.

@leihua-dev

@leihua-dev — on the one item left from your original report, the microphone.

It works here on the stock UCM profile, with no machine entry in
soc-acpi-intel-lnl-match.c at all. Same model as yours (Business, Intel;
268V rather than 266V), Ubuntu 26.04, kernel 7.0.0-30:

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

Your diagnosis is right, and it points somewhere useful. The monolithic
sof-sdca-1amp-id2.tplg base drops the SmartMic function — but the reason that
base gets loaded is that a machine entry was matched at all. Without one,
hda_sdw_machine_select() falls through to the generic path, which loads
sof-lnl-dummy.tplg and dispatches the SDCA functions itself, mic included, and
sets cfg-mics:1. That is the same thing ecf74df7 on v7.0-surface-devel
does by hand.

So on this hardware the machine entry appears to be the thing costing you the
microphone, not a missing piece of one.

What makes the generic path usable here is removing the ghost _ADR the
firmware declares (one physical RT1320 described twice, classes 0 and 1). Two
patches, sent upstream on 2026-08-30 — full detail and the rest of this
machine's status in
#1852 (comment):

https://lore.kernel.org/linux-sound/[email protected]/T/

Caveat: they are in review, not merged, and I have not run @AndreGilerson's
branch on this device — so this is my measurements against your reports, not one
machine tested both ways. I have offered upstream to do that comparison here and
will post the result either way.

@eidos-case

@eidos-case — I ran the comparison you offered: same machine, both paths, one unit.

Unit: Surface Pro for Business 11th Edition with Intel, SKU Surface_Pro_11th_Edition_With_Intel_For_Business_2103, Core Ultra 7 266V, BIOS 17.100.143 (2025-11-19). Arch Linux, sof-firmware 2025.12.2 (SOF v2.14.x topologies), alsa-ucm-conf 1.2.15.3, PipeWire 1.6.6.

The microphone works here now. arecord -l → card 0: sofsoundwire, device 4: Microphone; a 4 s capture gives peak −8.7 dBFS / RMS −33.5 dBFS. Speakers and HDMI unaffected.

One correction to the picture, for this branch

@AndreGilerson's v6.18-surface-devel (the commit I run, 8ab9347) does already carry an SP11 entry in soc-acpi-intel-lnl-match.c — but a pre-ecf74df7 one: .sof_tplg_filename = "sof-sdca-1amp-id2.tplg" together with .get_function_tplg_files = sof_sdw_get_tplg_files, and rt1320 still at dai_num = 1 in soc_sdw_utils.c. That produces exactly the symptom you diagnosed:

Using function topologies instead intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg
loading topology 0: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg
loading topology 1: intel/sof-ipc4-tplg/sof-hdmi-pcm5-id3.tplg

Monolithic base, no SmartMic. So why the mic is lost reads the same on 6.18. But removing the entry is not what fixes it here: on this branch the generic fallback never builds a Capture-SmartMic dailink at all, because rt1320's codec_info has no MIC DAI. What worked was completing the entry rather than deleting it.

What I changed

Five edits, all landing in modules — no kernel image rebuild, /boot untouched:

- 1. your two patches, verbatim apart from context adaptation of the dmi-quirks.c hunk (this branch has no ghost_realtek table yet).
– 5. the three non-lnl-match hunks of ecf74df7, backported from v7.0-surface-devel: the sof-sdca-1amp-dummy.tplg base name, rt1320's second codec_info DAI, and the forced Capture-SmartMic dailink name.

Dispatch is then identical to yours:

Using function topologies instead intel/sof-ipc4-tplg/sof-sdca-1amp-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

The ghost, confirmed independently

Before the quirk both _ADRs are present — sdw:0:0:025d:1320:00 permanently UNATTACHED, …:01 Attached — and ACPI enumerates the SDCA functions twice:

acpi device:28: find_sdca_function: SDCA function SmartMic (type 3) at 0x2
acpi device:29: find_sdca_function: SDCA function SmartAmp (type 1) at 0x4
acpi device:2b: find_sdca_function: SDCA function SmartMic (type 3) at 0x2
acpi device:2c: find_sdca_function: SDCA function SmartAmp (type 1) at 0x4

After patch 2/2, only the 2b/2c pair remains. Your DMI_PRODUCT_SKU key matches this unit exactly.

Caveat on my side: I changed all five things at once, so I cannot attribute the microphone to any single one of them. I did not bisect.

A flag for @AndreGilerson — this cost me a boot with no sound card at all

sof-sdca-1amp-dummy.tplg does not exist in any sof-bin release. I checked v2.14.x, the newest: 165 topologies, no *-dummy.tplg anywhere. And sof_select_ipc_and_paths() calls sof_test_topology_file() on .sof_tplg_filename unconditionally — before probe, and regardless of get_function_tplg_files:

Topology file: intel/sof-ipc4-tplg/sof-sdca-1amp-dummy.tplg
Check if you have 'sof-firmware' package installed.
error: sof_probe_work failed err: -2

Nothing registers — speakers included. My workaround points the dummy name at the real base:

/usr/lib/firmware/intel/sof-ipc4-tplg/sof-sdca-1amp-dummy.tplg -> sof-sdca-1amp-id2.tplg

which also degrades gracefully: should the function dispatch ever fail, it falls back to a working speakers-only topology instead of to no card.

What I find interesting is that this evidently does not bite you. Your log names sof-lnl-dummy.tplg, which does not exist either, yet your card comes up — so on 7.0's generic path the dummy name must be substituted after the profile check rather than before. If that is right, then a dummy name in a machine entry needs the file to exist, and a machine entry cannot pick up best-effort mode for free the way the generic path can. Worth settling before that entry goes anywhere near upstream.

Not done

I have not run v7.0-surface-devel itself, and I have not bisected the five changes. Happy to do either — this is a daily driver, but experiments are fine.

@leihua-dev

@leihua-dev — your correction is right, and I checked it instead of taking it on
trust. Both halves hold.

The rt1320 MIC DAI. On v6.18-surface-devel, soc_sdw_utils.c gives part
0x1320 exactly one DAI — rt1320-aif1, SOC_SDW_DAI_TYPE_AMP, .dai_num = 1.
On 7.0 there is a second one, rt1320-aif2 / SOC_SDW_DAI_TYPE_MIC /
SOC_SDW_DMIC_DAI_ID, .dai_num = 2. So on your branch the generic fallback has
nothing to build a capture link from. Removing the entry there would have left
you without a microphone by a different route.

What I got wrong. I wrote that "on this hardware the machine entry appears to
be the thing costing you the microphone". That is a statement about a kernel
version, and I phrased it as one about hardware. It holds on 6.19+. It does not
hold on 6.18 — and 6.18 is what you were running.

The dummy topology trap — settled, and in your favour

It is a version gap, not a generic-path-versus-machine-entry difference. There is
no provenance check anywhere in this path.

225d70b80745 "ASoC: SOF: don't check the existence of dummy topology" (Bard
Liao, 2025-10-14) adds a plain string test in fw-file-profile.c:

	/* Dummy topology does not exist and should not be used */
	if (strstr(profile->tplg_name, "dummy"))
		return 0;

It tests the name. It does not know, and cannot know, where that name came
from — so a machine entry gets exactly the same free pass the generic path gets.

And the generic path is not substituting the name after the check. It constructs
it up front, deliberately, for this precise purpose — sound/soc/sof/intel/hda.c:

	/*
	 * Set mach->sof_tplg_filename as a dummy topology to avoid tplg file checking
	 * and being used.
	 */
	mach->sof_tplg_filename = devm_kasprintf(sdev->dev, GFP_KERNEL,
						 "sof-%s-dummy.tplg", chip->platform);

Which tags carry it:

	`fw-file-profile.c` guard	`topology.c` `no_fallback`
v6.17	absent	absent
v6.18	absent	absent
v6.19	present	present

So vanilla 6.18 does not have it either. @AndreGilerson's branch is faithful to
its base; what ecf74df7 does is backport a machine entry written against a 6.19
convention onto a kernel that does not implement that convention. That is the
whole of the trap.

Worth noting what the commit message says upstream weighed and chose against:
"Instead of creating a dummy topology in the file system, we can skip the
existence check in the kernel." Your symlink is the alternative they named and
rejected — which makes it precisely the right workaround for a kernel predating
the choice.

To your closing question, whether a dummy name in a machine entry is safe to send
upstream: on 6.19+ it is the intended idiom and needs nothing settled.

One place your reasoning stops holding, if you ever move to 6.19+

You wrote that the symlink "degrades gracefully: should the function dispatch ever
fail, it falls back to a working speakers-only topology instead of to no card."

On 6.18 that is exactly right. topology.c there has no dummy handling at all, so
tplg_cnt == 0 falls through to tplg_files[0] = file unconditionally, and your
symlink makes that a real speakers-only topology.

On 6.19+ it would not. c8f3c9fa75ff made the fallback decision name-based too:

		bool no_fallback = strstr(file, "dummy");
...
	if (!tplg_cnt) {
		if (strstr(file, "dummy")) {
			dev_err(scomp->dev,
				"Function topology is required, please upgrade sof-firmware\n");
			return -EINVAL;

Existence is no longer consulted, so the symlink would stop buying you the
fallback. Harmless, but it would quietly stop being the safety net you built it
to be.

Incidentally that same commit was written for the symptom sitting in my own log:

sof_sdw sof_sdw: Failed to open topology file: intel/sof-ipc4-tplg/sof-lnl-ssp2-bt-id8.tplg

Its rationale — "some laptops present SSPx-BT link but we don't have fragment yet
to support this ... we should try to create the card with links that we support as
best effort instead of failing". That is why a missing fragment costs me one
absent link and cost you the whole card.

The ghost

Thank you for the before/after. The 2b/2c pair surviving alone after the quirk
is the same shape I measured here, and yours is a second unit with a different
BIOS. I am relaying it to the audio thread, which has had no review of the code
since 2026-08-05.

On your caveat: you changed five things at once and did not bisect. For the ghost
that does not matter — the duplicate _ADR and the doubled SDCA enumeration are
observable before any topology loads, and your before/after shows them changing.
The microphone is the attribution a bisect would sharpen, and I would not ask
anyone to bisect a daily driver for it.

Navigation Menu

Repository navigation

[Data] Surface Pro 11 (Intel Core Ultra 7 266V, Business Model) - Partial support, mic still missing #1876

33 remaining items

One correction to the picture, for this branch

What I changed

The ghost, confirmed independently

A flag for @AndreGilerson — this cost me a boot with no sound card at all

Not done

The dummy topology trap — settled, and in your favour

One place your reasoning stops holding, if you ever move to 6.19+

The ghost

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Data] Surface Pro 11 (Intel Core Ultra 7 266V, Business Model) - Partial support, mic still missing #1876

Description

Activity

JakobBerg commented on Oct 16, 2025

leihua-dev commented on Oct 18, 2025

noresttherein commented on Dec 23, 2025

Cloveian commented on Jan 6, 2026

noresttherein commented on Jan 13, 2026

wokawoka commented on Jan 19, 2026

AndreGilerson commented on Feb 11, 2026

noresttherein commented on Feb 14, 2026

AndreGilerson commented on Feb 14, 2026

oskaratk commented on Feb 24, 2026

AndreGilerson commented on Feb 24, 2026

FluorescentHallucinogen commented on Feb 24, 2026

Timeo04 commented on Feb 24, 2026

oskaratk commented on Feb 25, 2026

33 remaining items

Timeo04 commented on Mar 5, 2026

AndreGilerson commented on Mar 8, 2026

oskaratk commented on Mar 8, 2026

dankasfuk commented on Mar 11, 2026

oskaratk commented on Mar 11, 2026

dankasfuk commented on Mar 11, 2026

AndreGilerson commented on Mar 12, 2026

oskaratk commented on Mar 24, 2026

Timeo04 commented on Mar 26, 2026

leihua-dev commented on Jul 31, 2026

eidos-case commented on Aug 30, 2026

leihua-dev commented on Aug 30, 2026

One correction to the picture, for this branch

What I changed

The ghost, confirmed independently

A flag for @AndreGilerson — this cost me a boot with no sound card at all

Not done

eidos-case commented on Aug 30, 2026

The dummy topology trap — settled, and in your favour

One place your reasoning stops holding, if you ever move to 6.19+

The ghost

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions