[PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down

[PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down

[Sergey Lebedev]

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 */
 };
 

Test [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down

[German Pablo Lindo]

This patch solves the rotation error pointed out in in https://lore.kernel.org/linux-media/20260913144127.17995-1-germanpapulindez@gmail.com/ 


   Tested-by: German Pablo Lindo <germanpapulindez@gmail.com>

Re: Test [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down

[Sergey Lebedev]

Thank you. I will carry your tag to the next version.

I want to be sure I understand your result. Please answer yes or no:

  1. Is the image now correct on screen, not upside down?
  2. Did you check this in Gnome Snapshot?
  3. Did you check this in qcam?
  4. Did you check this in Firefox?
  5. Was it correct in the live preview, the moving picture?
  6. Was it correct in a photo file you saved?

Questions 5 and 6 matter most. A program can turn the picture on the screen
and still save the file the old way. I only tested saved files here.

If the answer to 1 is no, that is fine. It does not make the patch wrong.
The patch makes the kernel report the correct rotation. That is all it
claims to do.

I ask because I tested it here. I captured the same scene twice: once with
the patch, once without it. Both images are the same way up. The patch did
not turn the picture. It only changed the number libcamera reports, from 0
to 180.

So if your image is now correct, your program is turning it, using that
number. I could not see that here, and I would like to repeat what you did.
I have the same tablet. Please send:

  uname -r
  pacman -Q libcamera          (or your distribution's command)

and the version of whichever program showed the correct image.

If I can match your setup, I can find which program does the rotation. Then
it is a question for that program, not for the kernel.

Sergey

More details for Test [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down

[German Pablo Lindo]

The image is correctly flipped in Gnome and Firefox (the two i originally tested on) but in my original test i forgot qcam in which the image was not flipped ¿maybe it only flips Snapshot and Firefox because they use pipewire?

The preview in the three apps was fluent and the image saved corresponded to the image shown (rigth orientation for Snapshot, wrong for qcam)

Re: More details for Test [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down

[Sergey Lebedev]

Thank you. That is the answer, and it settles the question.

You have given me three things today that I could not have got on my own: a
test on a second machine, the cause of the colour error, and now this. I am
grateful for all three, and the last one I had asked for because I could not
test it here.

Your result and my measurement agree, and each explains the other. libcamera
does not rotate the image, and your qcam result is the evidence of that on
0.7.2. I measured the same here on 0.5.0: with the patch loaded I asked for
rot0, and it answered "Camera configuration adjusted" and returned the same
frame, the same way up. The sensor has no flip control, so libcamera tells
the application it cannot do it and hands the picture over unturned.

So qcam is right to show it upside down. qcam uses libcamera directly. And
your idea about pipewire is very likely the answer for the other two:
Snapshot and Firefox receive the frame through pipewire, which reads the
rotation property and applies it.

That is a better outcome for the patch than I expected. The kernel now
reports the mounting truthfully, and the two programs most people use act on
it:

  Gnome Snapshot    correct, in the preview and in the saved file
  Firefox           correct
  qcam              not flipped, which is the expected behaviour

For the patch itself, no change is needed. Its commit message already says
that an application reading the property can rotate and one ignoring it will
not, and your three programs have now confirmed both halves of that on a
second machine. Your Tested-by applies to it unchanged.

A v2 would only make that paragraph concrete by naming the programs, and I do
not think that earns a respin on its own. If a version is needed for any other
reason, it goes in then and I carry your tag into it by hand. So there is
nothing outstanding from me here.

Sergey

Re: [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down

[Sakari Ailus]

Hi Sergey,

On Sun, Sep 13, 2026 at 03:35:32PM +0000, Sergey Lebedev wrote:
> 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.

This commit message of a trivial patch is exceedingly long, please shorten
it. See examples of similar patches, for instance.

> 
> 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"),

Let's aim to keep these alphabetically ordered.

> +			DMI_EXACT_MATCH(DMI_PRODUCT_NAME,
> +					"Surface Pro for Business 11th Edition with Intel"),
> +		},
> +		.driver_data = "OVTID858",
> +	},
>  	{} /* Terminating entry */
>  };
>  
> 

-- 
Regards,

Sakari Ailus