Re: [PATCH] media: i2c: ov13858: add horizontal and vertical flip controls

[Sergey Lebedev]

Kieran,

You are right on all four. The bits are fine; the message was not.

1. The numbers are not an angle - nothing there is partly flipped.
   They are how the bits were found: every bit of 0x3820 through
   0x3823 written one at a time and ranked by correlation against a
   flipped reference, there being no public datasheet. "0.2" is a
   spread of 0.2 counts on a mean level of 70, from the same exercise.
   I included the working in case anyone later wanted more than the
   result; a commit message was the wrong place for it. v2 gives the
   result, and the method is yours for the asking.

2. I did check it myself, by eye, and that never reached the message.
   The four states are one contact sheet, which I have sent you
   directly rather than here because it is a 101 KB attachment:

     <EViHAe8VXLnuCLNW2WvrH9wZvJzSwWcAsaS16-dxkYEdCDlpHnQyQpkcfcEGYIIQ1jRO0ChI_aIXf-HNYdroAOlCbEg-BXux6yw76GGfA94=@pm.me>

   Unflipped is upside down, which is what userspace gets today;
   hflip+vflip is the one the right way up. Say the word and it goes to
   anyone else here.

3. The mirror bit is active low, and ov13b10 does the same:
   ov13b10_set_ctrl_hflip() clears BIT(3) of 0x3820 and
   ov13b10_set_ctrl_vflip() sets BIT(4) | BIT(5) of it. v2 says so at
   that line, rather than only in the defines at the top of the file.

Which makes this, in my own message, untrue:

> ov13b10 has the same two controls, but it is a different part and its
> bit assignments do not carry over.

They carry over exactly. BIT(5) differs only in where the mode tables
leave it - 0x88 and 0x8b there, 0xa8/0xab/0xac here - leaving this part
only BIT(4) to move. The real difference is the other way round:
ov13b10 shifts H_WIN_OFFSET and V_WIN_OFFSET on each flip to reverse
the Bayer order, and this one does neither. v2 says why, from the
picture rather than a statistic.

Thanks for the fast read.

Sergey