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@xxxxx>
> ---
> 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@xxxxx/
> 
> 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@xxxxxxxxx/
>   https://lore.kernel.org/linux-media/20260903080854.16266-1-germanpapulindez@xxxxxxxxx/
> 
> 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