[dfattal]

What

Moves the Linux SR SDK pin (Track B Deb job in build-linux.yml) from 1.37.0.10693 to 1.38.0.10108, the first Linux SDK that ships the SR compose API.

• Release: sr-sdk-v1.38.0.10108 on LeiaInc/SR-SDK-Windows-Releases-Internal-Public
• Asset: LeiaSR-SDK-1.38.0.10108-linux64.tar.gz
• sha256: c6c13a6e813112afb43376bd7c8c1a6c47e001964d9b522fa308d3cae4621dd8 (verified locally against the downloaded asset)
• Layout is unchanged from 1.37.0.10693 (include/sr, lib/libsrSDK_loader.a, lib/cmake/srSDK).
• New in the headers: srWeaverSetComposeInputsVulkan (loader slot 94), srWeaverSetComposeOrder (81), srWeaverSetComposeLayerUnchanged (84), srWeaverSetComposeFilterStrength (85). srWeaverSnapToPhase and srWeaverSetPresentOrigin are still present, so the Linux release .deb is built without srWeaverSnapToPhase — window drags never phase-snap, and the stub declines silently #271 snap gate keeps passing.

Download hardening

• The job downloads the exact SR_SDK_ASSET instead of probing tar.gz|tgz|tar.xz|zip.
• It refuses an SR_SDK_ASSET that does not belong to SR_TAG (LeiaSR-SDK-$SR_TAG-linux64.*).
• New SR_SDK_SHA256 check: a hash mismatch is a hard error on PRs and tags alike. Before this there was no integrity check.
• The behaviour on a missing asset is unchanged: soft-skip on a PR or branch, hard error on a v* tag.

Not touched

• The Windows pins (SR_TAG 1.35.0.2011 / SR v2 in build-windows.yml + build-windows.bat) and the Android CNSDK pin.
• check_sr_pins.py still passes. It deliberately does not compare the Linux SR_TAG.

Coordination with #304 and #301

This PR on its own changes nothing in the shipped binary's feature set. It only makes the SDK side of #301's build probe answer yes. The 2D-under-the-lens feature needs all three PRs:

PR	provides
#304	runtime pin v2.26.0 → XRT_DP_VK_HAS_OVERLAY_2D (+ _FILTER_STRENGTH) in the DP headers
this	SDK 1.38.0.10108 → srWeaverSetComposeInputsVulkan / SetComposeOrder (+ v14/v15 probes) in the loader
#301	the feature code, compiled in only when both of the above are present

The PRs are independent: each is green on main alone. The combined-branch CI evidence is in a comment below.

Files: .github/workflows/build-linux.yml, docs/linux-track-b-runbook.md, src/drv_leia_linux/CMakeLists.txt (the snap-gate FATAL_ERROR text now names the new SDK).

🤖 Generated with Claude Code

[dfattal]

Combined-branch proof (main + #304 + #301 + this PR)

Throwaway branch tmp/combined-2d-under-lens-proof = origin/main merged with #304 (1426c43), #301 (87b6ae1) and this PR (73ef10c), plus one evidence-only step. It was not opened as a PR and will be deleted. CI run: https://github.com/DisplayXR/displayxr-leia-plugin/actions/runs/37363353140 (job Deb (Track B, ubuntu:22.04): success).

LeiaSR-SDK-1.38.0.10108-linux64.tar.gz sha256 OK (c6c13a6e813112afb43376bd7c8c1a6c47e001964d9b522fa308d3cae4621dd8)
-- DisplayXR-LeiaSR: drag phase-snap ENABLED (srWeaverSnapToPhase declared + linkable from .../_srsdk/leiasr-sdk-1.38.0.10108+ge97551277c/include)
-- DisplayXR-LeiaSR: SR weaver 2D compose (2D under the lens) ENABLED +v14 cache hint +v15 filter strength
==> Drag phase-snap: srWeaverSnapToPhase present (7 string hits)

Runtime side: the shipped DisplayXR-LeiaSR.so contains the XRT_DP_VK_HAS_OVERLAY_2D branch literal YES (the SR side is probed on the first layer), so the set_overlay_2d slot is compiled in at runtime pin v2.26.0. DebInstall passed on 22.04, 24.04 and 26.04.

Each of #304, #301 and this PR is green on main alone. Suggested merge order: #304 → #306 → #301. The feature PR goes last, once both prerequisites are on main, and the final state equals the combined branch above.

🤖 Generated with Claude Code