Re: [PATCH v3 0/3] media: Add support for the Sony IMX681

[Sergey Lebedev]

German,

Thank you - a second machine, which the v3 cover letter named as the
limitation it most wanted lifted. Your report also found something real.

Your inverted image is the driver
=================================

Prompted by it I held a sheet of printed text in front of the camera and
captured one raw frame: /dev/video16, SGRBG10, a crude 2x2 debayer, nothing
clever. The text came out reversed, and flipping the frame horizontally makes
it read correctly. So the sensor output is horizontally mirrored, always -
not rotated, not flipped vertically.

The other half of that result is worth saying: apart from the mirror the frame
is an ordinary photograph. No tearing, no skew, no diagonals, no wrong
geometry.

The cause is in the init sequence, with the author's comment:

    /* Image orientation: H-flip to match Windows AIQB (RGGB native -> GRBG) */
    { CCI_REG8(0x0101),  0x01 },

The flip makes the Bayer order GRBG, which is what the driver advertises and
what Intel's tuning expects, so the format declaration is honest. The geometry
is not declared at all: there is no V4L2_CID_HFLIP, and camera_orientation
says only that the camera faces front, not that frames arrive mirrored.

Which is why one of your applications is right and the other is not. A front
camera is conventionally mirrored by the application. An app that does that
applies a second flip and gets the true scene - qcam, Firefox. An app that
does not shows our output backwards - Snapshot. Both are behaving sensibly;
the driver put them in that position by transforming the image invisibly.

It is fixable above the driver, so nobody is stuck - but only if userspace
knows, and today it cannot find out.

Bug, or acceptable? I would like the list's view
================================================

There is a case for acceptable: the flip is part of the mode, the advertised
Bayer code matches what is really on the bus, and a front camera ends up
mirrored anyway. I lean the other way: your two applications are what it looks
like when a consumer cannot learn about the transform. But that is one machine
and one opinion, and the code is Andre's, who is back on 28 September.

If it is a bug, two shapes:

  1. RECOMMENDED. Keep the flip, expose V4L2_CID_HFLIP defaulting to 1, and
     swap the advertised code with it - SGRBG when set, SRGGB when clear.
     Nothing changes for anyone who does nothing, and the transform becomes
     visible and controllable. imx415 exposes both flips but does not vary its
     code, so the tree is not a clean precedent.

  2. Drop the flip and advertise SRGGB10, leaving mirroring to userspace.
     Cleaner as a driver, but it changes the advertised format - the very
     thing the flip exists to control - and would likely break the setup you
     have working.

1 costs no existing user anything, which is why I recommend it; 2 is the
better driver if the AIQB turns out not to require GRBG, and that is Andre's
to say. Sakari, Dan, Hans - a view either way settles it and I will do the
work.

Two notes alongside that. Nothing here blocks anyone - the camera is usable as
it stands, as your own report shows. This is about making the driver honest,
not about making it work.

And I have an open thread on libcamera-devel about this sensor's delays, still
waiting on a reply:

  https://lists.libcamera.org/pipermail/libcamera-devel/2026-September/061928.html

libcamera consumes precisely what is in question here - sensor orientation and
the flip controls - so a view from that side bears directly on which option is
right. I have not cross-posted this, because it is a kernel-side decision
first, but I will carry the answer across once there is one.

Your other notes
================

The colour cast with light level, the brightness drift and the snow all look
like AE, AWB and tuning, none of which this driver has: it exposes exposure,
blanking, two gains, link frequency, pixel rate and a test pattern, and that
is all.

Two guesses of mine were wrong, so skip them: the capture node's padded line
(7744 bytes for a 3844-pixel row) would draw about nineteen diagonals, not
your one; and imx681_MSHW0520, MSHW0580 and MSHW0580Second are byte-identical
.aiqb files here, so the variant cannot change colour.

One question that is ours
=========================

v3 changed the gain ABI and you tested v3. Up to v2, V4L2_CID_ANALOGUE_GAIN
advertised 0..1020 and quietly drove the digital gain register above code 960,
so one control could reach 256x; in v3 it stops at 960, the 16x the analogue
stage actually does. If your HAL drives only ANALOGUE_GAIN it now has sixteen
times less range - so did brightness behave differently on v1 or v2? If you
only ran v3, saying so is just as useful.

If you are comfortable with it, a

  Tested-by: German <germanpapulindez@xxxxxxxxx>

would carry weight: a second machine and a second userspace stack. It would
not be claiming Snapshot works or that the tuning is right.

Thanks again.

Sergey