[widgetii]

Moves hisilicon-opensdk from 7270ab5 to e02be20, one commit: OpenIPC/openhisilicon#293.

What it fixes. With the exposure direction fixed (#2775), the CV2003 camera in OpenIPC/majestic#355 was still dark and noisy. Its shutter-start register read 6000:

• the driver stretched the frame for majestic's slow shutter, and counted the shutter start against the longer frame;
• that put the shutter opening past the end of the frame the sensor ran, leaving almost no exposure;
• AE then made up for it with gain.

The vendor's own CV2003 driver has no slow shutter: it keeps the frame at 2400 lines, caps exposure at 2390, and never writes VMAX. The driver now does the same.

Scope. Only CV2003 cameras: no other file changes between the two pins. They lose long night exposures, as they have on stock firmware.

Verification

• The driver cross-builds with no warnings; openhisilicon CI is green, and Qodo found no issues.
• Read from the vendor's driver in that camera's stock firmware (cmos_slow_framerate_set).
• Not yet run on a CV2003. The owner in use the latest available commit hash instead of the HEAD pointer. #355 is checking the equivalent setting, isp.slowShutter: disabled, on the camera.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Bump openhisilicon to fix CV2003 slow-shutter exposure

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Pins openhisilicon to e02be20, incorporating the upstream CV2003 slow-shutter fix.
• Restores stock-style frame and exposure limits to address dark, noisy images; hardware
 verification remains pending.

Diagram

graph TD
  PIN["Buildroot pin"] --> SOURCE["openhisilicon source"] --> DRIVER["CV2003 driver"] --> SENSOR["CV2003 sensor"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Disable slow shutter through camera configuration

• ➕ Avoids changing the SDK dependency pin.
• ➖ Requires configuration on each affected camera and leaves the driver behavior unchanged by default.

Recommendation: Use the upstream pin: it addresses the reported behavior at the driver boundary without requiring per-camera configuration. Keep hardware validation as an explicit follow-up before treating the image-quality fix as confirmed.

Files changed (1) +1 / -1

Other (1) +1 / -1

hisilicon-opensdk.mkPin openhisilicon to e02be20 +1/-1

Pin openhisilicon to e02be20

• Changes the fetched openhisilicon revision from 7270ab5 to e02be20. According to the PR description, the intervening upstream commit removes CV2003 slow-shutter frame stretching and caps exposure to the standard frame.

general/package/hisilicon-opensdk/hisilicon-opensdk.mk

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. CV2003 fix merged without camera proof 📘 Rule violation ≡ Correctness

Description

The version bump at line 8 moves HISILICON_OPENSDK_VERSION to e02be20, which changes CV2003 frame
length and exposure on the camera and so changes what the firmware does. The Verification section
leaves its hardware checkbox unchecked with "Not yet run on a CV2003", and no before/after camera
output is given, so the change reaches images without the evidence this gate requires.

Code

general/package/hisilicon-opensdk/hisilicon-opensdk.mk[8]

+HISILICON_OPENSDK_VERSION = e02be20059d9fa11dec6058cb50bfff2de202300

Evidence

The version bump at line 8 pulls in a driver change that alters CV2003 exposure and frame timing.
The PR description's Verification section has an unchecked box, "Not yet run on a CV2003", and no
before/after camera output, so the failure criteria for compliance 3 are met.

Rule 3: Hardware evidence is present and honest
general/package/hisilicon-opensdk/hisilicon-opensdk.mk[8-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR bumps `hisilicon-opensdk` to e02be20, changing CV2003 exposure and frame behaviour on real cameras. The PR description's Verification section leaves the hardware checkbox unchecked and includes no before/after evidence from a CV2003.
## Fix Focus Areas
- general/package/hisilicon-opensdk/hisilicon-opensdk.mk[7-8]
## Recommended Fix
Run the image on a CV2003 with and without the bump, using `isp.slowShutter: disabled` as the baseline. Record dmesg or logs, a measured exposure or brightness comparison, and a stream sample. Check the box in the PR description and paste the output under the Verification heading. If the hardware test cannot happen before merge, state that plainly and mark the change as unverified on hardware.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[widgetii]

On the hardware-evidence finding: the PR states plainly that this is untested on a CV2003. The owner in OpenIPC/majestic#355 is the one testing it, through the equivalent setting (isp.slowShutter: disabled) on the camera now, and the fix itself on the nightly. The change follows the vendor's own driver, read from that camera's stock firmware, and it touches CV2003 cameras only. Those currently produce a dark, noisy picture, so a CV2003 camera is not left worse off.