Stop shipping a dangling /etc/sensors/iq/default.ini - #150
Merged
Conversation
The osdrv packages create default.ini as a symlink to one fixed sensor's
IQ file -- imx307.ini for hisilicon-osdrv-hi3516ev200 and
goke-osdrv-gk7205v200. Two device profiles prune that exact file to fit
NOR and leave the symlink behind, so the image ships a default.ini that
resolves to nothing.
majestic answers that silently. init_iq_monitor() (src/hisi/sdk.c) has no
default for isp.iqProfile, falls through to /etc/sensors/iq/default.ini,
and returns on `access(default_prof, 0) != 0` without logging at any
level. No IQ profile means no monitor thread, so SCENE_Set3DNR() never
runs and VPSS keeps the single static NRX block from scene.c tune_vpss()
at every ISO. The explicit-iqProfile path does log "Cannot find %s file";
only this fallback is mute.
Measured on a lab hi3516ev300_85h50ai (IMX335, nightly-20260904-605fa9d)
against a night scene at ISO ~30000, changing nothing but the profile
majestic loads:
dangling imx335.ini
RTSP, 20 s capture 14.13 Mbit/s 3.54 Mbit/s
/proc/umap/rc InsBr 14310 kbps 3626 kbps
StartQp 42 (= MaxQp) 31
3DNR SFS2 5/16/0/30 36/60/60/52
3DNR TFS 1/7/12/10 5/9/13/11
The encoder was configured correctly the whole time -- VBR 4096, MinQp
28, MaxQp 42. Rate control pinned at MaxQp while still emitting 14 Mbit/s
is what an undenoised sensor at ISO 30000 costs, not a bitrate that was
ignored. It reads as "the bitrate setting does nothing" and "3DNR is
off", which is how it was reported.
hi3516ev300_lite_xm-85h50ai keeps imx335.ini and runs an IMX335, so
general/overlay now carries a default.ini aimed at it. BR2_ROOTFS_OVERLAY
is rsynced after the packages install and rootfs_script.sh runs the
excludes list after that, so the overlay's symlink replaces the package's
and the pruning that follows is harmless. This also stops the board
loading an IMX307 profile for an IMX335 sensor, which is what it would
have got had imx307.ini simply been kept.
gk7202v300_lite_ipg-g3-wr prunes every IQ file its package installs
(imx307, imx335, sc2232), so there is nothing to aim a symlink at. It
drops default.ini instead. Behaviour is unchanged -- majestic already
loads no profile there -- but the image stops carrying a broken link that
would silently start resolving to the wrong sensor's profile the moment
one of those entries goes stale. The board runs jxh63, which no shipped
IQ file covers; a note in the list records that keeping imx307.ini costs
126 KB if it turns out to want one.
An audit of every device profile against its SoC's osdrv package finds no
others: the rest either keep the symlink's target, remove default.ini
already, or pin .isp.iqProfile in customizer.sh.
widgetii
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
September 6, 2026 19:44
PR Summary by QodoPrevent dangling default IQ profiles in two device images
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reported as two symptoms on a lab
hi3516ev300_85h50ai:video0.bitrateset to 4000 kbit/s while the WebUI dashboard showed 14.2 Mbit/s, and visibly noisy video that looked like 3DNR was off. They are one bug, and it is in this repo.What happens
The osdrv packages create
default.inias a symlink to one fixed sensor's IQ file —imx307.inifor bothhisilicon-osdrv-hi3516ev200andgoke-osdrv-gk7205v200. Two device profiles prune that exact file to fit NOR and leave the symlink behind, so the image ships adefault.inithat resolves to nothing:majestic answers that silently.
init_iq_monitor()(src/hisi/sdk.c) has no default forisp.iqProfile, falls through to/etc/sensors/iq/default.ini, and returns onaccess(default_prof, 0) != 0without logging at any level. No IQ profile means no monitor thread, soSCENE_Set3DNR()never runs and VPSS keeps the single static NRX block fromscene.c tune_vpss()at every ISO.Measured
Lab
hi3516ev300_85h50ai(IMX335,nightly-20260904-605fa9d), night scene at ISO ~30000, changing nothing but the profile majestic loads:imx335.ini/proc/umap/rcInsBrStartQpMaxQp)The encoder was configured correctly the whole time —
/proc/umap/rcshowedVBR 4096, MinQp 28, MaxQp 42. Rate control pinned atMaxQpwhile still emitting 14 Mbit/s is what an undenoised sensor at ISO 30000 costs, not a bitrate that was ignored. It reads from the outside as "the bitrate setting does nothing" and "3DNR is off", which is how it was reported.The fix
hi3516ev300_lite_xm-85h50aikeepsimx335.iniand runs an IMX335, sogeneral/overlaynow carries adefault.iniaimed at it.BR2_ROOTFS_OVERLAYis rsynced after the packages install androotfs_script.shruns the excludes list after that, so the overlay's symlink replaces the package's and the pruning that follows is harmless. Simulated end to end:This also stops the board loading an IMX307 profile for an IMX335 sensor, which is what it would have got had
imx307.inisimply been kept instead — so it is a better outcome than reverting the exclusion, at the same size.gk7202v300_lite_ipg-g3-wrprunes every IQ file its package installs (imx307, imx335, sc2232), so there is nothing to aim a symlink at. It dropsdefault.iniinstead. Behaviour is unchanged — majestic already loads no profile there — but the image stops carrying a broken link that would silently start resolving to the wrong sensor's profile the moment one of those entries goes stale. The board runsjxh63, which no shipped IQ file covers; a note in the list records that keepingimx307.inicosts 126 KB if it turns out to want one. That call belongs to whoever has the hardware.Blast radius
Audited every device profile against its SoC's osdrv package (
default.initarget: imx307 for hi3516ev200/gk7205v200, sc2232 for gk7205v500, ar0130 for hi3516cv200, imx323 for hi3516cv300). These two are the only ones that remove the target while keeping the symlink. The rest either keep the target, removedefault.inialready, or pin.isp.iqProfileincustomizer.sh.One thing the audit turned up that is not fixed here:
/etc/sensors/iq/*.iniingk7205v200_lite_vixand-ipc-1is a dead entry — the excludes runner quotes its paths, so the glob never expands and nothing is pruned. Harmless, but it is not doing what it looks like it does.Follow-ups worth doing separately
rootfs_script.shafter the excludes run would catch this whole class at build time, next to the existing stale-entry report.log_w()on the mutedefault.inifallback. The explicit-iqProfilepath already logsCannot find %s file; only this one is silent, which is why this took proc-file archaeology rather than reading a log.imx307.inihas an IMX335 camera loading the IMX307 IQ profile. A labhi3516ev300-imx335is doing that today and looks fine, because a wrong profile still carries usable 3DNR ISO tables — the failure is quiet in that direction too. Resolvingdefault.iniper detected sensor would fix the class.