gpio-motors: read the pin list from ptz_gpio, keep gpio_motors working

[openipc-ai]

Completes the PTZ variable rename from OpenIPC/majestic-webui#227 on the utility side.

The WebUI now uses explicit ptz_* names (ptz_control picks the method; ptz_gpio is the documented pin list) and already accepts either name for detection — but gpio-motors itself was the one place still demanding gpio_motors, forcing every new setup to use the legacy name and leaving the rename half-done.

• ptz_gpio is read first; gpio_motors remains the fallback (every camera configured before the rename has it, including the published recipes).
• grep . turns an empty first answer into a failure so the || genuinely falls through instead of handing an empty line to the parser.
• Error message and the package Readme name both variables; the Readme's per-device examples keep the legacy name they were published with.

cc @flyrouter — this is the "one hunk in the firmware repo" from the #227 reply.

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

PR Summary by Qodo

Prefer ptz_gpio with legacy gpio_motors fallback

🐞 Bug fix 📝 Documentation 🕐 Less than 10 minutes

AI Description

• Prefer documented ptz_gpio pin lists while preserving gpio_motors compatibility.
• Treat empty ptz_gpio values as missing so legacy fallback executes.
• Document both variable names for new and existing camera setups.

Diagram

graph TD
  ENV[("Firmware env")] --> PTZ["Read ptz_gpio"] --> FILTER["Nonempty filter"] -->|value| PARSE["Parse pin list"] --> CONFIG["GPIO motor config"]
  FILTER -->|empty or missing| LEGACY["Read gpio_motors"] --> PARSE

Loading

High-Level Assessment

The preferred-first lookup with a legacy fallback is the best fit for completing the variable rename without breaking deployed cameras. Performing the fallback in the existing environment-read path keeps the change narrow and preserves the parser unchanged.

Files changed (2) +11 / -3

Bug fix (1) +7 / -2

gpio-motors.cLoad PTZ pins from the current or legacy environment variable +7/-2

Load PTZ pins from the current or legacy environment variable

• Reads 'ptz_gpio' first and falls back to 'gpio_motors' when the preferred value is missing or empty. The configuration error now identifies both accepted variables.

general/package/gpio-motors/src/gpio-motors.c

Documentation (1) +4 / -1

Readme.mdDocument ptz_gpio as the preferred pin-list variable +4/-1

Document ptz_gpio as the preferred pin-list variable

• Changes the basic setup example to use 'ptz_gpio' and explains that 'gpio_motors' remains supported for existing cameras and published device recipes.

general/package/gpio-motors/Readme.md

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

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📜 Skill insights (0)

1. ptz_gpio lacks hardware evidence 📘 Rule violation ☼ Reliability

Description

The installed gpio-motors binary now gives ptz_gpio precedence when selecting the persistent
environment value that controls physical motor GPIOs, but the PR provides no affected-board test,
selector/parse output, or before/after runtime evidence. Consequently, ptz_gpio precedence,
empty-value behavior, and the legacy gpio_motors fallback remain unverified on real firmware
despite the potential to change camera motor behavior.

Code

general/package/gpio-motors/src/gpio-motors.c[125]

+		"fw_printenv -n ptz_gpio 2>/dev/null | grep . || fw_printenv -n gpio_motors", "r");

Evidence

PR Compliance IDs 1 and 41 require hardware evidence for changes capable of altering camera
behavior. The command added at line 125 runs at runtime to select the GPIO configuration, which is
parsed into the physical pan/tilt pin arrays, and the package makefile installs this binary into the
target image; however, the PR description identifies no affected board and provides no before/after
real-hardware output for the renamed key, empty-value behavior, or legacy fallback path.

Rule 1: Hardware evidence is present and honest
general/package/gpio-motors/src/gpio-motors.c[125-125]
general/package/gpio-motors/src/gpio-motors.c[119-146]
general/package/gpio-motors/gpio-motors.mk[10-16]
Best Practice: Repository guidelines

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 changes the persistent environment-variable selection used by the installed `gpio-motors` binary, potentially altering which physical GPIOs drive camera motors, but provides no observable test evidence from an affected camera.

## Issue Context
Record the affected board and provide before/after command, selector/parse, or runtime output showing that `ptz_gpio` is selected when populated, the expected behavior when it is empty, and that the legacy `gpio_motors` value remains a working fallback. If real hardware cannot be accessed, state that plainly and provide the strongest available selector or parser test evidence.

## Fix Focus Areas
- general/package/gpio-motors/src/gpio-motors.c[125-125]

ⓘ 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 enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗