Re: [PATCH 0/2] parse horizontal/vertical flip properties

[Hans de Goede]

Hi,

On 23-Jul-25 12:09 PM, Fabian Pfitzner wrote:
> On 7/23/25 11:44, Jacopo Mondi wrote:
>> On Wed, Jul 23, 2025 at 11:29:27AM +0200, Fabian Pfitzner wrote:
>>> On 7/23/25 11:17, Jacopo Mondi wrote:
>>>> Hi Fabian
>>>>
>>>> On Wed, Jul 23, 2025 at 10:58:28AM +0200, Fabian Pfitzner wrote:
>>>>> There are cameras containing a mirror on their optical path e. g. when
>>>>> mounted upside down.
>>>> How is this different from 'rotation = 180' ?
>>> If you simply want to flip the output (e. g. horizontally), you cannot do
>>> this with a rotation.
>>> The camera I'm referring to is not only upside down, but also flipped
>>> horizontally.
>> 180 degress rotation = HFLIP + VFLIP
> I do not want to do both. Only one of them.
>>
>> Yes, you can't express 'mirror' in DTS, because DTS are about the
>> physical mounting rotation of the camera. Sensor drivers shall not
>> apply any flip control automatically, it's userspace that by parsing
>> the rotation property through the associated v4l2 controls should decide
>> if it has to apply flips or not to correct the images.
>>
>> What is the use case you had in mind ? Tell the driver through a DTS
>> property it has to apply flips to auto-compensate ? Because I think we
>> shouldn't and if I'm not mistaken we also document it:
>> https://www.kernel.org/doc/html/latest/userspace-api/media/drivers/camera-sensor.html#rotation-orientation-and-flipping
> I have a camera that does a horizontal flip in its hardware, so the output is not what I want. My example above was misleading. The rotation fixes the "upside down" problem, but does not fix the flip.

Hmm, so is there anything in the optical path causing just
a horizontal flip ? 

Because if not it sounds like the driver is simply buggy and
is applying hflip by default / applying hflip while the hflip
control is set to 0.

We've had this case a couple of times before. So it might just
be that we need to fix the driver here ...

Regards,

Hans