From: Sergey Lebedev <lsa.uz@pm.me>
To: linux-media@vger.kernel.org
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans de Goede <hansg@kernel.org>,
Dan Scally <dan.scally@ideasonboard.com>,
German Pablo Lindo <germanpapulindez@gmail.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down
Date: Sun, 13 Sep 2026 15:35:32 +0000 [thread overview]
Message-ID: <20260913153526.80287-1-lsa.uz@pm.me> (raw)
The Microsoft Surface Pro for Business 11th Edition with Intel mounts its
OV13858 rear sensor rotated 180 degrees and declares it in neither the SSDB
nor a matching _PLD, so the rotation reads as 0 and every frame arrives
inverted with nothing to say so.
Add it to upside_down_sensor_dmi_ids, the table that exists for this class
of firmware. Matched on DMI_PRODUCT_NAME as the rest of that table is; the
entry only takes effect when the ACPI HID matches too, so a machine of the
same model that shipped a different rear sensor is left alone.
Measured on the machine. Before:
camera_sensor_rotation min=0 max=0 value=0
libcamera: Property: Rotation = 0
After:
camera_sensor_rotation min=180 max=180 value=180
libcamera: Property: Rotation = 180
and the front sensor is untouched at 0.
This makes the kernel report the mounting truthfully, and that is all it
does. The pixels are unchanged: capturing one static scene through
libcamera with the property at 0 and at 180 and correlating the vertical
brightness profile gives +0.995 the same way up and -0.781 flipped, so
libcamera delivers the same buffer either way. The sensor has no flip
controls, so nothing is corrected in hardware either.
An application that reads the property can now rotate; one that ignores it
still shows the image inverted. That is a userspace matter and is not
addressed here.
Signed-off-by: Sergey Lebedev <lsa.uz@pm.me>
---
Written 2026-08-31 against a variant of upside_down_sensor_dmi_ids that
takes a struct with a match type and an id list. No such variant exists in
media/next, so the patch could never have applied and was never sent;
rewritten today in the form the table actually uses, and measured.
Applies to media/next on its own and on top of
https://lore.kernel.org/linux-media/20260913142034.5632-1-lsa.uz@pm.me/
which adds the OVTID858 bridge entry the same machine needs.
A second machine reporting the same DMI product name independently reports
the same inverted image, in three different applications:
https://lore.kernel.org/linux-media/20260913144127.17995-1-germanpapulindez@gmail.com/
https://lore.kernel.org/linux-media/20260903080854.16266-1-germanpapulindez@gmail.com/
I have asked its owner to confirm the string and to say whether any of those
three applications turns the picture the right way up once the property is
set. It would surprise me if they did.
drivers/media/pci/intel/ipu-bridge.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 7e65491faf..a5de450284 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -192,6 +192,14 @@ static const struct dmi_system_id upside_down_sensor_dmi_ids[] = {
},
.driver_data = "OVTI02E1",
},
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME,
+ "Surface Pro for Business 11th Edition with Intel"),
+ },
+ .driver_data = "OVTID858",
+ },
{} /* Terminating entry */
};
next reply other threads:[~2026-09-13 15:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 15:35 Sergey Lebedev [this message]
2026-09-13 17:01 ` Test " German Pablo Lindo
2026-09-17 11:52 ` Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260913153526.80287-1-lsa.uz@pm.me \
--to=lsa.uz@pm.me \
--cc=dan.scally@ideasonboard.com \
--cc=germanpapulindez@gmail.com \
--cc=hansg@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®