Fedora Account System
Red Hat Associate
Red Hat Customer
Hardware: Dell XPS 13 9315 Sensor: ov01a10 (i2c-OVTI01A0:00, address 18-0036) libcamera version: 0.7.1 Kernel: 7.0.9-204.fc44.x86_64 No ov01a10.yaml tuning file exists upstream. libcamera falls back to uncalibrated.yaml, causing AGC oscillation and brightness flickering, especially under artificial lighting (50Hz mains, Spain). Workaround in place: manual /usr/share/libcamera/ipa/simple/ov01a10.yaml with relativeLuminanceTarget: 0.12, speed: 0.01, flickerPeriod: 10000. This reduces but does not eliminate flickering on scene changes. lsmod relevant output: intel_ipu6_isys, intel_ipu6, ipu_bridge, ivsc_csi, ivsc_ace, ov01a10 Reproducible: Always Steps to Reproduce: 1. Use Dell XPS 13 9315 with Fedora 44 and libcamera 0.7.1 2. Open any camera application (tested with qcam, Firefox/Google Meet) 3. Use camera under artificial indoor lighting (LED/fluorescent, 50Hz mains) Actual Results: Webcam brightness flickers continuously. Flickering worsens under artificial lighting and when scene content changes (e.g. someone entering the frame). libcamera falls back to uncalibrated.yaml because no ov01a10.yaml tuning file exists, causing AGC oscillation. Expected Results: Webcam should produce stable brightness without flickering. A proper sensor tuning file for the ov01a10 (as used in Dell XPS 13 9315) should be shipped with libcamera to replace the uncalibrated fallback. Additional Information: Sensor: ov01a10 (i2c-OVTI01A0:00, address 18-0036) Hardware: Dell XPS 13 9315 Kernel: 7.0.9-204.fc44.x86_64 Partial workaround: manual ov01a10.yaml with relativeLuminanceTarget: 0.12, speed: 0.01, flickerPeriod: 10000 reduces but does not eliminate flickering. Tuning file and libcamera debug log attached.
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.