[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: [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