[PATCH] media: ipu-bridge: Add upside-down sensor quirks for the Surface Pro 9

[PATCH] media: ipu-bridge: Add upside-down sensor quirks for the Surface Pro 9

[Fernando Rimoli]

The Microsoft Surface Pro 9 mounts both its front sensor (OVTI5693) and
its rear one (OVTID858) rotated 180 degrees, and its SSDB reports 0 for
each, so frames from either arrive inverted with nothing to say so.

Add both to upside_down_sensor_dmi_ids. The two entries carry identical
DMI matches and differ only in the ACPI HID they gate on, which works
because ipu_bridge_parse_rotation() walks every matching DMI entry rather
than stopping at the first one.

Measured on a Surface Pro 9, DMI product SKU Surface_Pro_9_2038, IPU6
Alder Lake-P 8086:465d, where the inversion of both sensors was confirmed
visually. Matched on DMI_PRODUCT_NAME as the rest of the table is, rather
than on the narrower SKU: the entries only take effect when the ACPI HID
matches too, so a variant of the same model that shipped different
sensors is left alone.

This makes the kernel report the mounting truthfully and does no more
than that. Nothing in the bridge rotates pixels, so an application that
reads the property can turn the image the right way up while one that
ignores it still shows it inverted.

Signed-off-by: Fernando Rimoli <fernandorimoli11@gmail.com>
---
Applies to media/next as it stands today.

Two notes for whoever sequences this against Sergey Lebedev's Surface Pro 11
entry, which is in flight for the same table:

  https://lore.kernel.org/linux-media/20260913153526.80287-1-lsa.uz@pm.me/

Both his entry and mine go in immediately before the terminating entry, so
whichever is applied second needs a one-line context fix. Nothing else in the
two overlaps: different machines, different HIDs.

Separately, and only because it would be a shame for it to be dropped
silently: his version as posted does not apply to the current tip. Its hunk
context ends at the Samsung Galaxy Book5 Pro 360 entry (OVTI02E1), while the
table now ends with the Book3 Ultra (960XFH, OVTI02C1), so his base predates
that entry. A rebase is all it needs.

I have not touched the Surface Pro 9 rear sensor's own bridge entry here.
That is Sergey's patch, which I tested separately:

  https://lore.kernel.org/linux-media/20260913142034.5632-1-lsa.uz@pm.me/

 drivers/media/pci/intel/ipu-bridge.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 952868a..f286881 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -226,6 +226,22 @@ static const struct dmi_system_id upside_down_sensor_dmi_ids[] = {
 		},
 		.driver_data = "OVTI02C1",
 	},
+	{
+		/* Microsoft Surface Pro 9, front sensor */
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Surface Pro 9"),
+		},
+		.driver_data = "OVTI5693",
+	},
+	{
+		/* Microsoft Surface Pro 9, rear sensor */
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Surface Pro 9"),
+		},
+		.driver_data = "OVTID858",
+	},
 	{} /* Terminating entry */
 };
 

Re: [PATCH] media: ipu-bridge: Add upside-down sensor quirks for the Surface Pro 9

[Sergey Lebedev]

Two things your commit message says are ones I have checked on the Surface
Pro 11, so for what it is worth from another submitter rather than a
reviewer.

That nothing in the bridge turns pixels - measured. One static scene captured
through libcamera with the property at 0 and at 180, vertical brightness
profiles correlated: +0.995 the same way up against -0.781 flipped. Asking
explicitly for rot0 with the entry in place makes libcamera answer "Camera
configuration adjusted" and hand back the same frame - it tells the
application it cannot, rather than doing it. That was on a 7.3.0-rc1 built
from media/next with libcamera 0.5.0, on a Surface Pro 11 for Business
(Intel), firmware 17.105.143.

What happens above the bridge, which your last paragraph leaves open, has an
answer now too. German Pablo Lindo tested the SP11 entry on a second
machine. The image is correct in Gnome Snapshot and in Firefox, and still
inverted in qcam. His reading is that the first two take the frame through
pipewire while qcam talks to libcamera directly. So an application that reads
the property does turn the image the right way up; the one that ignores it is
qcam.

That the entry only fires when the HID matches - read rather than measured.
ipu_bridge_parse_rotation() walks every DMI match rather than stopping at the
first, and returns 180 only where acpi_dev_hid_match() also succeeds. That is
what makes DMI_PRODUCT_NAME safe for a model that might have shipped
different sensors, and it is the same reasoning behind the SP11 entry.

On your note that mine no longer applies
========================================

You are right, and I would rather be exact about where, because the tree
decides it. Checked today:

  media/next, 27953c0449        table ends 960QHA / OVTI02E1    mine applies
  mainline master               no 960XFH                       mine applies
  linux-next                    has 960XFH                      conflict

The 960XFH entry is Felipe Calliari's Samsung Book3 Ultra patch of
2026-09-05, which has reached linux-next but not media/next. So as posted mine
still applies to the tree it is aimed at. It stops doing so when that entry
arrives there, and then it wants exactly the one-line fix you describe - as
does yours, for the same reason.

Thank you for raising it rather than letting it be found later.

Sergey