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

[Sergey Lebedev <lsa.uz@pm.me>]

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