[ooaklee]

Summary

Integrates the downstream Surface Pro 11 kernel and Ubuntu 7.2.x line for both supported Denali variants:

• X1E80100 / OLED — MSHW0485 product 045e:0c83
• X1P42100 / LCD — MSHW0485 product 045e:0c80

The branch now brings together SP11 device-tree, driver, packaging, configuration, and CI work for direct touch, iptsd-backed pen input, volume buttons, native audio and microphone capture, platform power profiles, battery-provider selection, and the IMX681 front camera.

This is intentionally a broad downstream integration line rather than an upstream-ready subsystem patch series.

Highlights

Touch, pen, and buttons

• Adds the in-tree MSHW0485 HID-over-SPI touchscreen path for X1E/OLED and X1P/LCD.
• Keeps the kernel driver as the sole direct-touch and panel-mode owner while exposing a bounded HIDRAW-only DFT sibling for unmodified iptsd v3.1.0 stylus processing.
• Relays only the required DFT reports, keeps transport state separate from HID client data, and ties bridge recreation to controller recovery generations.
• Promotes the live-validated Phase 84 IPTS initialization and level-low, one-response-per-IRQ cadence as the shared default profile.
• Retains the bounded /dev/g6ts-heat export for diagnostics; pressure, tilt, and button events use the DFT/iptsd path.
• Wires and enables both volume-up and volume-down on the device tree.

Audio and microphones

• Ports the Golden v33 native SP11 playback path: protected SP/SPVI AudioReach graph, VI+CPS feedback, Windows-ordered calibration/volume/mute handling, WSA8845 lifecycle fixes, TOP_CFG1 physical-lane parity, and SoundWire feedback-port Offset2 parity.
• Adds stereo TX-macro DMIC capture while retaining the VA capture path.
• Shares the VA-owned physical DMIC clocks with the TX macro, validates the Denali 19.2 MHz divider and EP16 routing, and limits the new behavior to microsoft,denali.
• Includes the SP11 WSA884x 2-speaker/4-ohm profile and PA-fault recovery.

Power and battery

• Makes platform_profile available on the DT-only SP11 through a non-ACPI kobject fallback while preserving the legacy sysfs path expected by power-profiles-daemon.
• Adds per-policy FREQ_QOS_MAX CPU caps, late cpufreq-policy handling, and an SP11 low-power boot default.
• Skips the duplicate SAM battery provider on Denali so Qualcomm battmgr remains authoritative for both variants.

Front camera

• Adds the standalone Sony IMX681 front-camera path for X1E/OLED: 3840x2640 packed RAW10, 24-bit exposure plus gain controls, and the validated 2.406-Gsymbol/s X1E80100 C-PHY profile.
• Routes CCI1.1 -> CSIPHY2 -> CSID0 -> VFE0 RDI0 and describes MCLK4, power rails, reset, and the privacy LED.
• Enables the driver in the Ubuntu ARM64 configuration; the existing D-PHY path remains unchanged.
• Limits this scope to the front RGB camera; rear and IR/Windows Hello support remain follow-up work.

Platform integration

• Carries the SP11/Denali device trees, SPI-HID support, display/DP and DWC3 fixes, kernel configuration, Ubuntu packaging/changelog updates, and integration-branch CI policy.
• Tracks the wider jg/ubuntu-qcom-x1e-7.2.y kernel line, so the comparison also contains inherited QCOM arm64, DRM, media, networking, platform-driver, and core-kernel work.

Additions after the original recorded tip

The previous description's validation section stopped at 5cf0b8835858. The current head adds the following SP11 integration work:

Head or merge	Added scope
b6ca0e494a9b	DT-only platform-profile support, CPU frequency caps, and low-power default
537d1ac61225	Golden v33 native speaker/audio parity
3fc7c5249f4a	X1P touchscreen product support and Denali battery-provider selection
58e36b1acb04	Stereo TX DMIC capture
d915d679423e	IMX681 C-PHY front-camera support
2cbd1ec3e2da	HIDRAW/iptsd pen bridge, transport-lifetime fixes, IPTS init, IRQ cadence, and shared X1E/X1P defaults

That range contains 18 commits touching 61 files, with 8,520 insertions and 878 deletions.

Validation status

• Current head: 2cbd1ec3e2da385e7bd91fd65c63ba5a8fb5b865.
• Pen on X1E/OLED: Phase 84 was hardware-validated on 7.2.0-jg-0sp11v19-qcom-x1e; hover, contact, pressure, tilt, barrel button, and concurrent one-/two-/three-finger touch worked with no transport errors, recovery failures, daemon restarts, or kernel taint in the acceptance run. X1P uses the same promoted profile, but separate X1P pen qualification remains outstanding.
• X1P direct touch: hardware-validated with product 045e:0c80; descriptor validation and physical touch completed successfully.
• Native playback: hardware-validated on X1E/OLED with the v9/v10 packages, including stereo output and the Golden v33 feedback/lane-order fixes.
• TX DMIC capture: the integration and git diff --check passed in the constituent PR; Linux hardware capture and regression testing were still outstanding there.
• Power profiles: profile enumeration, switching, and frequency QoS were hardware-validated on the v8 package.
• Front camera: repeated and continuous RAW10 capture, gain/exposure response, zero reported CSID/VFE transport errors, libcamera processing, PipeWire publication, and Firefox Google Meet preview were hardware-validated on X1E/OLED.
• Integration checks: the fork's SP11 integration validator passed at the exact current head; it checks patch hygiene and the SP11-authored checkpatch gate, not a full kernel build. The target PR currently reports no checks.
• Validation varies across the inherited integration history; see the linked constituent PRs for exact commands, kernels, evidence, and remaining qualification items.

Integration state

The target and integration branches have advanced independently since this PR opened, and GitHub currently reports merge conflicts. The large comparison includes inherited kernel and Ubuntu history and is not a count of SP11-authored patches. The branch must be synchronized with the current target before merge.

Links

• Current base-to-head comparison
• Power-profile design and verification record
• Camera design and verification record

[jglathe]

When you do changes in drivers that are not exclusively written for the SP11 (and usually have a hardware /firmware detection in probe()), you need to gate your changes against the "common" use case, as you did in the qspi code for gpi DMA. The gating is easiest with check agaunst the dt, of_ compatible=microsoft,denali. The of_ structure is also in the device descriptor or can be easily reached.
Work from 7.2.y, yes. It is easier to integrate these parts. And good preparation for the upstreaming part 😁
I've seen another thing: You disable the cl4 idle state, my tree disables the cl5 idle state for stability. From the comment this read differently, like a resume issue. Could it be a bit too much? Disabled idle states draw more power.

[jglathe]

All current open PRs are drafts. That qspi patch is a big one, I don't have hardware that uses the spi at all (to my knowledge). Maybe a public call for testing on Ubuntu Discourse helps to verify the changes. There are quite a few people with Dell Laptops, they could help, probably. The sp11v21 pre-compiled package would be a good start. A bit of a testing dilemma.

[jglathe]

Also, I have set up a Matrix room for sp11/12 bringup: https://matrix.to/#/#sp11_12_linux:matrix.org
Might be a more immediate way of communication. I use element-desktop as client.

[ooaklee]

@jglathe, it doesn't seem like I can join; I've tried the web and desktop. What account did you invite? Do you have Discord? If so, add me there, please: typicalleee

Via the desktop app, I am seeing
MatrixError: [403] You are not invited to this room. (https://matrix-client.matrix.org/_matrix/client/v3/join/%23sp11_12_linux%3Amatrix.org?server_name=matrix.org&via=matrix.org)

[ooaklee]

All current open PRs are drafts.

The majority are ready to go; I only put them in draft to make sure we follow the order we agreed on

That qspi patch is a big one, I don't have hardware that uses the spi at all (to my knowledge). Maybe a public call for testing on Ubuntu Discourse helps to verify the changes.

That's a shout; I'll make lexr.sh public shortly, then get it to build that Image and get feedback

[jglathe]

Do you have a user name on Matrix? I need this to invite you. Mine is @jglathe:matrix.org

[ooaklee]

@jglathe, posted a message requesting testers

I've also made lexr public, so if you want to give it a spin, please see:

• https://github.com/ooaklee/lexr.sh/blob/main/docs/getting-started/install.md
• https://github.com/ooaklee/lexr.sh/blob/main/docs/user-guide/install-released-kernel-and-userspace.md

[ooaklee]

October 4: retire old submission versions; keep this coordination thread

The repaired combined source is now 8ba2b75713feb5c72bbc11dd8cce4048e23cdeea, ABI 7.2.5-jg-0sp11v8-qcom-x1e, based on the current release-line tip e57ec2987d4540fa89280d349f79c4d9bcd7cf27. Its ordinary-use results and outstanding acceptance items are tracked in ooaklee/linux_ms_dev_kit-sp11#68; the same source is published as an experimental v8 release, not a fully qualified release.

We are withdrawing older submission versions #83–#91 rather than leaving obsolete 7.2.2 heads as active merge requests. Their branches, commits, contributor credit, source links and discussions remain intact. This PR stays open, as requested, as the original coordination/provenance thread—not a proposal to merge the whole integration branch.

Current fork review: ooaklee/linux_ms_dev_kit-sp11#51 carries the refreshed inherited Denali/touch/pen/sensor/C-PHY/graph prerequisites; ooaklee/linux_ms_dev_kit-sp11#56 covers additional CAMSS parity, ooaklee/linux_ms_dev_kit-sp11#57 TX, ooaklee/linux_ms_dev_kit-sp11#58 playback, ooaklee/linux_ms_dev_kit-sp11#59 battery, ooaklee/linux_ms_dev_kit-sp11#60 native profiles, and ooaklee/linux_ms_dev_kit-sp11#61 additional GPI ordering. These are not upstream-ready successor submissions. The two additional deferred GPI corrections remain explicitly deferred without changing tested v8 source.

After exact combined acceptance, supporting provenance and appropriate shared-driver checks, we will reconstruct focused author-preserving upstream topics against the then-current release tip. TX precedes playback; battery precedes profiles. The requested non-SP11 X1E boot check remains necessary before shared audio reaches the release line. Fork-only integration scripts/workflows and repository policy will never be included in those submissions. No merge or default-branch promotion is implied by this cleanup.

[ooaklee]

October 4: bounded combined v8 camera/audio follow-up

Combined fork review #68 now records the successful
three-cycle camera/reopen/indicator check in Power Saver with concurrent quiet
built-in-speaker playback on unchanged source 8ba2b75713feb5c72bbc11dd8cce4048e23cdeea, ABI
7.2.5-jg-0sp11v8-qcom-x1e. Stop snapshots have zero ECC/CRC and VFE
violation/overflow values; frame-drop information flags and undecoded RX status
remain limitations. Durable qualification report.

This closes that bounded check, not every camera mode, physical speaker
protection, shared-device acceptance or the remaining CI/provenance/deviation
gates. The test applies to the separate v8 source, not this PR's historical
integration head. This PR remains a coordination thread, not a broad merge
request. The requested non-SP11 X1E boot check still precedes shared audio
release-line acceptance, and focused successors will exclude all fork-only CI.

[lain3d]

Adding a small historical source-preservation handoff to this coordination thread, not proposing a branch merge. I've released my abandoned X1E80100 OLED/Wi-Fi research at https://github.com/lain3d/surface-pro-11-research and the experimental kernel at https://github.com/lain3d/surface-pro-11-kernel. The default main includes the front-camera driver and associated receiver/PHY work.

The platform material that may be useful is the ADSP/USB-C external-root investigation. In our August experiment, retaining UCSI registration across charger_pd restart removed the orientation-NONE teardown, but storage still disconnected: that change was not a complete external-root fix. Attaching to the smaller boot ADSP image preserved PD but did not provide adsp_apps/audio. Later boot experiments and their limits are retained in the archive; I am not suggesting a live ADSP restart on USB-root.

This work builds on your kernel and denisix's platform contributions; the 2.4 MHz DMIC and baseline SPI work were prior art, not my discoveries. Your newer integration has moved substantially beyond the old baseline. The release is unmaintained and experimental, with no request to merge the old WIP branches or claim they satisfy current shared-device acceptance.