S97qrscan periodic GPIO toggles cause visible brightness pulses in live image on cameras where led1 is sensor-visible

[widgetii]

Summary

The S97qrscan init service shipped by general/package/quirc-openipc toggles the led1 GPIO in a loop while attempting QR-code Wi-Fi onboarding. On cameras where led1 controls a light that is visible to the image sensor (e.g. IR LED, status LED in the lens FOV, or any GPIO line wired to a visible-spectrum source near the sensor), the toggles show up as brightness pulses in the live image for ~200 ms per toggle, at the cadence of the qrscan retry/restart loop.

Observed on the dlab lab cam openipc-hi3518ev200.dlab.torturelabs.com (hi3518ev200_lite_switcam-hs303 builder variant, soi_f22 sensor):

• led1 resolves to GPIO-34 via /usr/share/openipc/gpio.conf on this board.
• 20 s sampling of the RTSP stream at 10 fps, 160×90 luma mean:
  • qrscan running: 9 spikes at exact 5 s cadence, baseline luma 106 → spike luma 154-157 (~50 % brighter). Spike pairs (two adjacent frames per pulse, ~200 ms width).
  • qrscan killed + GPIO-34 driven low: 200 frames, baseline 109.0, stdev 0.16 (0.15 % variance), no spikes.
• Stable image fully returns; the kernel/i2c/AE stack is correct, the visible "flicker" is 100 % the qrscan GPIO pulses.

The same GPIO pulse path likely affects every camera variant whose gpio.conf maps led1 to a sensor-visible source. The qrscan default behaviour is gated on a non-empty wlandev U-Boot env var, so most non-Wi-Fi builds escape it — but any Wi-Fi-equipped variant currently has visible brightness pulses overlaid on the live image during the (~30 s) onboarding-retry window after every boot, plus on any retry restart.

Reproduction

# On a camera with wlandev set + qrscan running:
ssh root@<cam> 'logread | grep qrscan'
# May 27 13:23:43 user.notice qrscan: Recognition timeout exceeded, reboot camera and try again...
# May 27 13:23:43 user.notice gpio: Setting GPIO-34 to HI
# ...repeats every retry cycle

# Capture frame-brightness sampling:
ffmpeg -rtsp_transport tcp -i rtsp://root:12345@<cam>:554/stream=0 \
    -frames:v 200 -vf 'fps=10,scale=160:90' -f image2 /tmp/f%03d.png

# Then compute per-frame luma mean — pulses are visible as periodic spikes.

Reproducer file (general/package/quirc-openipc/files/qrscan.sh)

The toggle calls happen here:

# top of the script, before the loop
gpio toggle ${gpio} | logger -t gpio

while true ; do
    if [ "$n" -ge 30 ]; then
        logger -t qrscan "Recognition timeout exceeded, reboot camera and try again..."
        gpio toggle ${gpio} | logger -t gpio
        exit 1
    fi
    ...

${gpio} defaults to led1 from /usr/share/openipc/gpio.conf. Whether that line affects the image is per-board; on hi3518ev200_lite_switcam-hs303 it does.

Suggested directions (for discussion, not prescriptive)

1. Don't toggle led1 from qrscan at all — use a dedicated qrscan_indicator line in gpio.conf so boards can choose to remap or leave unset (no-op).
2. Don't auto-run qrscan on every Wi-Fi-capable boot — gate behind a separate env var like wlanenroll=1 so production deployments don't get visible pulses on every reboot. The current [ $(fw_printenv -n wlandev) ] check fires whenever a Wi-Fi adapter is configured at all, including normal post-onboarding operation.
3. Use a non-image-visible indicator — sound output (/play_audio is already used on the success path), serial console message, or no indicator at all during retries.

I have the lab cam available for testing candidate fixes.