Repository navigation
contrib: Surface Pro 11 (Intel) — camera tuning and face login - #2267
eidos-case wants to merge 6 commits into
Conversation
The Intel version of the Surface Pro 11 needs two things that cannot come from a kernel patch. Its three cameras enumerate and stream with current kernels but produce unusable pictures without libcamera tuning data, which is per-sensor and per-board. The three files here were measured against the same scenes shot under Windows; the README says what is deliberate about them, what they do not fix on their own, and which upstream patches they still depend on. The Bluetooth entry is a workaround, marked as one: a missed alive interrupt in btintel_pcie aborts the whole system suspend, and two patches fixing it are on linux-bluetooth. It should be deleted once either lands.
|
Twenty-three days without a review, so a nudge — but with an offer rather than It adds two unrelated things at once: a Bluetooth resume workaround and What has moved upstream since I opened it, in case it bears on whether the
The README's two "not merged" notes are still accurate, though, and I checked No urgency from me — the files run here either way. |
The recovery script reloaded btintel_pcie as soon as the adapter showed a zero address, which is also what it shows while the firmware setup is still running. The unload then frees the interrupts under that setup, and the probe of the reload fails with -62, leaving no adapter at all. On this machine it did that on every boot it acted on. It now treats a zero address as dead only after 15 s, reloads at once when no driver is bound, checks that the unload took, tries a second reload if the first gives no address, and exits non-zero if neither did. The README described a suspend problem, which this entry does not address. It recovers the controller when a firmware-download race leaves it dead at boot; the README now says that, and how to tell whether you need it.
|
Updated the Bluetooth entry, and a correction to my last comment. The recovery script in this PR could kill the controller it was meant to The README was also wrong about what the entry is for. It recovers the Details, including the part I got wrong on the list: |
ov13858.yaml carried Intel's colour matrices for this module, read out of the Windows driver's tuning data. These files should carry only what was measured on this machine, so the Ccm block goes. The black level stays. One of the matrices' two colour temperatures, 5960 K, also had no source. The README said the cameras enumerate and stream with current kernels. No release has the front or infrared driver, and the rear sensor needs patches that are not in a release yet. It now says so, points at the status discussion for the current list, and gives where the libcamera helper stands. Its provenance names what is measured. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…ernel The README said the race had not appeared on 7.2 and 7.3 kernels built with a smaller configuration. Mainline v7.0 built with Ubuntu's own configuration came up clean on 41 boots of 41, so it is in Ubuntu's kernel and not in mainline. It now says so and links the Launchpad bug. Co-Authored-By: Claude Opus 5.5 <[email protected]>
| nothing to do with suspend. | ||
|
|
||
| **This is a workaround, not a fix, and you may not need it.** The race is in | ||
| Ubuntu's kernel, not mainline: v7.0 built with Ubuntu's own configuration came |
There was a problem hiding this comment.
This repo is about the linux-surface kernel, not the Ubuntu kernel. Please test whether your workaround is needed with the 7.0 kernel support added in another PR
There was a problem hiding this comment.
Thanks. I haven't tested a linux-surface kernel. What I have: Ubuntu's 7.0.0-34
hit the race on 9 boots of 28, while mainline v7.0 and bluetooth-next, both
built here with Ubuntu's own config, came up clean on 41 of 41 each
(Launchpad 2161900).
I haven't narrowed down what in Ubuntu's kernel brings it in, and the 7.0.y
stable updates are among the candidates, so a linux-surface 7.0 kernel may race
too.
Since the race has only been seen on Ubuntu's kernel, I've dropped the
workaround from this PR, which is the camera files only now. It's in #2268 for
anyone who meets the race.
The race this works around was seen only on Ubuntu's kernel: it hit 9 boots of 28 on Ubuntu's 7.0.0-34, against none of 41 on mainline v7.0 built with Ubuntu's own configuration. What in Ubuntu's kernel brings it in is not known, the 7.0.y stable updates under it among the candidates, and no linux-surface kernel was tested, so the workaround does not belong here. The race is reported as Launchpad bug 2161900, and the workaround moves to the device's status discussion, linux-surface#2268. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…IR driver With vd55g0 v5 and later the infrared sensor reports itself as Y8/Y10, and libcamera 0.7 has no software ISP for monochrome: the camera offers only raw R8, R10 and R10_CSI2P, and validate() replaced the XRGB8888 the reader asked for without a word. The reader read every frame as XRGB8888 and gave Howdy a quarter-width picture, in which it found no face in any of 573 frames. It now asks for a format it can read, checks that libcamera kept it, reads R8 as such (and R10, untested here), and takes the sensor's full frame for a raw format. On 7.3-rc1 with vd55g0 v6, Howdy's own steps found a face in all 398 frames at 644x604. The README names the check, says vd55g0.yaml does not apply to a mono driver, and lists the IPU7 snoop fix, which the infrared picture also needs. Co-Authored-By: Claude Opus 5.5 <[email protected]>
eidos-case
changed the title
This branch has not been deployed
2 participants
Camera tuning for the Intel version of the Surface Pro 11, the part that cannot
come from a kernel patch at all, following the
contrib/layout.The Bluetooth workaround that was here is gone. The race it works around was
seen only on Ubuntu's kernel, and no linux-surface kernel was tested, so the
workaround does not belong here; it now lives in
#2268.
surface-pro-11-intel-camerasThree cameras — rear
ov13858, frontimx681, infraredvd55g0. None of themworks with a stock kernel yet: the front and infrared sensors have no driver in
any release, and the rear one needs the patches listed in
#2268. Even
with those, the picture is unusable without tuning data, which is per-sensor and
per-board and does not come from upstream. These files carry only what was
measured on this machine, the black levels. Intel's colour matrices, read out of
the Windows driver's tuning data, worked here, but neither colour file has one:
the rear file's was removed on 2026-10-03, and the README says why.
The README is explicit about three things that would otherwise look like bugs in
the files:
camera also needs a libcamera sensor helper, and the infrared picture needs an
IPU7 fix that went to linux-media on 2026-10-07. It says so, and points at
#2268 for the current list,
so that nobody blames the tuning;
Ccmandvd55g0.yamlhas noAgc, alldeliberate, with the reasons given so nobody "fixes" them;
across releases — a colour matrix that gave a neutral-grey spread of 1.06 on
0.7.0 gave 13.9 on master.
Also included is a Howdy recorder plugin that reads the IR camera through
libcamera's Python bindings, since Howdy expects a V4L2 device and the IR camera
is not usable that way here. Three non-obvious constraints in it are documented,
one of them new on 2026-10-07: with the infrared driver going upstream,
libcamera hands the plugin raw monochrome frames, and the plugin had read them
as colour, which left Howdy nothing to recognise. It now reads them as what
they are.
Provenance
One machine: Surface Pro for Business 11th Edition with Intel, SKU
Surface_Pro_11th_Edition_With_Intel_For_Business_2103, Core Ultra 7 268V, UEFI17.100.143 (17.105.143 from the end of August), Ubuntu 26.04, kernel 7.0.0-30,
libcamera 0.7.0. The plugin was last checked on 7.3-rc1 with the infrared driver
going upstream. ACPI dumps for this machine are in
linux-surface/acpidumps#34,
not merged yet.
The full device status is in
#2268, since
the patch situation changes weekly and does not belong in a file.