IR cut GPIO detection reports wrong pin (heuristic fails on output-HIGH IR cut)

[widgetii]

Problem

gpio_possible_ircut() in src/reginfo.c uses a heuristic that reports GPIOs which are output direction + LOW value as possible IR cut pins. This produces incorrect results on cameras where the IR cut GPIO is output + HIGH in steady state.

Example: Hi3516AV200 camera

ipctool reports:

board:
  possible-IR-cut-GPIO: 11

Physical testing result: GPIO 11 is NOT an IR cut pin. The actual IR cut is GPIO 63 (group 7, bit 7), which is output=HIGH in day mode.

Root cause

The filter condition at reginfo.c:2682:

if ((direct & bit_mask) && ((value & bit_mask) == 0))

Only matches output pins that are currently LOW. Many IR cut designs use HIGH = day mode (filter removed), so the actual IR cut pin is filtered out while unrelated LOW-output pins are reported as false positives.

Investigation

Tested on a real Hi3516AV200 camera with vendor streamer robcat:

1. /proc/<pid>/maps of the streamer reveals exactly which GPIO groups it has memory-mapped via /dev/mem:

   • 0x12141000 → GPIO group 1
   • 0x12147000 → GPIO group 7

2. Physical toggle test of all output pins in those groups confirmed only GPIO 63 (group 7, bit 7) actuates the IR cut filter.

3. A proof-of-concept shell script (tools/find_ircut.sh) validates the /proc/maps approach — it correctly narrows candidates to the streamer-mapped GPIO groups.

Proposed fix

Replace the heuristic with a /proc/*/maps-based detection:

1. Scan /proc/*/maps for userspace processes that have GPIO register regions mapped via /dev/mem
2. Report all output pins in those mapped GPIO groups (regardless of HIGH/LOW value)
3. Fall back to the current heuristic when no /proc/maps matches are found

This works because streamers (majestic, robcat, Sofia, etc.) must mmap GPIO registers to control IR cut hardware.