Bug 2483190

Created attachment 2143333 [details]
libcamera debug log

Created attachment 2143334 [details]
My current tuning file

FTR., this should be fixed in 0.7.2 by commit "ipa: libipa: camera_sensor_helper: Add OV01A10" (https://gitlab.freedesktop.org/camera/libcamera/-/commit/ffa3e38950db8341fad3d5f95907231dff2ecf5a)

Thanks for the pointer in comment #3. 0.7.2 does fix the original oscillation,
but it turns out to expose a second bug that causes a worse one.

soft_simple.cpp derives the AGC's minimum gain step from 1% of the gain range.
For the OV01A10's 1-63.9961 range that is 0.63 at unity gain, where the sensor
resolves 1/256. So the AGC computes a 2% correction and applies a 63% one,
every frame, and never settles:

    again 1.00000  error +0.51  factor 1.020 -> applied 1.62996
    again 1.62996  error -0.41  factor 0.984 -> applied 1.00000

It only shows once exposure saturates and gain is the only control left, which
is why qcam looked fine while a browser flickered constantly.

Deriving the step from what the sensor can actually resolve fixes it:

    context_.configuration.agc.againMinStep =
            camHelper_->gain(againMin + 1) -
            context_.configuration.agc.againMin;

which gives 0.00390625 here. Gain then tracks continuously instead of
alternating between two values. I have been running it for a day, in qcam and
in video calls, and the flicker is gone.

Robert — since this is a libcamera bug rather than a packaging one, would you
rather I opened a GitLab issue, sent the patch to libcamera-devel, or would you
prefer to take it upstream yourself? Happy either way.

One thing worth flagging for Fedora meanwhile: shipping 0.7.2 to F44 without
this would give other XPS 13 9315 users a constant flicker rather than 0.7.1's
intermittent one.

Ouch, too bad :(

> One thing worth flagging for Fedora meanwhile: shipping 0.7.2 to F44 without this would give other XPS 13 9315 users a constant flicker rather than 0.7.1's intermittent one.

Could you give bad karma on https://bodhi.fedoraproject.org/updates/FEDORA-2026-6766d18fde

> Robert — since this is a libcamera bug rather than a packaging one, would you rather I opened a GitLab issue, sent the patch to libcamera-devel, or would you prefer to take it upstream yourself? Happy either way.

It would be awesome if you could take this to libcamera-devel / send a patch!

P.S.: thanks for testing btw.!

If you have some cycles, could you maybe have a look at the pending AGC rework in https://patchwork.libcamera.org/project/libcamera/list/?series=6125 - and check if that maybe already does something similar?

Looks like the commit mentioned above that landed in 0.7.2 was split out from the following series: https://patchwork.libcamera.org/project/libcamera/list/?series=5915

That has several commits which appear to be related to the issue you describe.

Robert, thanks for both pointers, and sorry for the slow reply — I wanted to
test the rework first.

5915 does not contain a fix, but it explains the cause. Patches 01/10 (the
OV01A10 sensor helper) and 05/10 (proportional controller replacing bang-bang)
both landed for 0.7.2. The againMinStep formula predates them — it is already in
v0.7.1 — and was harmless there: without a helper the gains are raw register
codes, so the minimum step was one code, and bang-bang always asked for ~10%,
well above it. Patch 01 switches the units, making that step 0.63 at unity gain
for this sensor; patch 05 makes the controller ask for ~2% near the target.
Either alone is fine; together every correction is rounded up to 63%.

I tested 6125 as well, since you asked. It fixes this, by removing the mechanism
rather than correcting it: with a CameraSensorHelper present,
AgcAlgorithm::init() selects AgcMeanLuminance, which has no gainMinStep.
Measured on the ov01a10 against a plain-master control, the 0.63 quantum
accounts for half of master's gain movements and essentially none with 6125
applied.

Measurements and the rest of the detail are in a report I have sent to
libcamera-devel, currently held for moderation — subject "Bug: ipa: simple: AGC
limit cycle from againMinStep derived from range". I will add the archive link
here once it appears.

Thanks Milan for unpushing FEDORA-2026-6766d18fde. Whenever 0.7.2+ is revisited
for F44 it will need the rework, or an equivalent fix, first.

Also from 5915: the six patches that did not land cover other things I ran into
— the OV01A10 tuning file (04), Adjust reading gamma/contrast from YAML (03),
AGC reading its parameters from YAML (08). The simple IPA ignores all of those
tuning keys silently, and recipes setting them circulate for IPU6 laptops.

Disclosure: I investigated this with an AI assistant (Claude), which did much of
the code archaeology and analysis. The measurements are from my own hardware and
I have verified the conclusions myself.

Upstream report, and a hotfix for a possible 0.7.3:

https://lists.libcamera.org/pipermail/libcamera-devel/2026-August/061529.html
https://patchwork.libcamera.org/patch/28080/

If a 0.7.3 lands, that is what F44 and F45 would want.

FEDORA-2026-c1dcc53f06 (libcamera-0.7.2-4.fc46) has been submitted as an update to Fedora 46.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-c1dcc53f06

FEDORA-2026-c1dcc53f06 (libcamera-0.7.2-4.fc46) has been pushed to the Fedora 46 stable repository.
If problem still persists, please make note of it in this bug report.