Re: Test for [PATCH] media: ipu-bridge: add the OV13858 rear sensor

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

Thank you - and no, you did not forget to apply a patch. There was nothing to
forget. The rotation fix existed only on my disk, because I had written it
against a form of upside_down_sensor_dmi_ids that does not exist upstream, so
it never applied and I never sent it. You found a real bug and the gap was
mine. It is on the list now, rewritten against the table as it actually is:

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

Your September report is the reason it matches the way it does. You wrote:

  Surface Pro for Business 11th Edition with Intel

which is this machine's DMI_PRODUCT_NAME here, character for character, so
the entry matches on that rather than on the SKU I had originally used. If
that string came from /sys/class/dmi/id/product_name on your machine rather
than from a specification sheet, the patch covers you as written. Worth
confirming, since one is evidence and the other is marketing:

  cat /sys/class/dmi/id/product_name /sys/class/dmi/id/product_sku

Then, and please do not expect it to work: apply it and look at Snapshot,
qcam and Firefox again. I think the picture will still be upside down in all
three, and I would like to be wrong.

Why it probably will not fix what you saw
=========================================

The firmware describes the sensor as not rotated, so libcamera reports
Rotation = 0 and no application has any reason to turn the image. The patch
makes the kernel report Rotation = 180 instead. That is all it does.

I captured one static scene twice here, once with the property at 0 and once
at 180, and correlated the vertical brightness profile: +0.995 the same way
up, -0.781 flipped. libcamera hands out the same buffer either way, and the
sensor has no flip controls, so nothing is corrected in hardware either.

So the kernel stops lying and whether anyone acts on the truth is a userspace
question. You have those three applications set up and I do not. If one of
them rotates once the property is right, that is worth knowing. If none do,
that is a userspace bug to file, not a kernel one - and it is a much better
answer than the one I could give by guessing.

About the tag
=============

Carried, and you were right to flag that you tested v1: the v1 and v2 diffs
are byte-identical, only two over-long lines in the commit message changed,
so your Tested-by transfers unchanged.

Nothing needed from you - but the trailer is indented three spaces again, the
same thing I mentioned on your imx681 tag. It costs nothing here because I
carry these by hand, and I mention it only so tooling works for you later:
git send-email keeps the leading whitespace, and b4 and patchwork both match
trailers only at the start of a line.

Sergey