Decouple DDC Capture Identity and improve DDC resilience

[rodrgz]

This change improves external monitor support in two related areas: it separates the identifier used for brightness control from the identifier used for Wayland output capture, and it makes DDC brightness control more tolerant of flaky direct DDC access.

• Add capture_name as an optional config field for backlight and ddcutil outputs.
• Keep name as the brightness-device identity while using capture_name only for Wayland output matching.
• Make DDC control more resilient by slowing DDC transitions, retrying direct DDC reads/writes, and falling back to the ddcutil CLI when raw DDC access is unreliable.
• Add a clear warning when no Wayland output matches a configured capture target.

The changes are split into three commits so the config/capture-name part, the direct DDC retry/timing changes, and the CLI fallback can be reviewed separately. I can split this into separate PRs if preferred.

Problem

External DDC monitors can require two different identifiers:

• The DDC layer may only be reliably identifiable by serial number.
• The Wayland compositor may expose the same monitor under a connector- or model-based description.

Before this change, wluma used a single name field for both concerns. That created a mismatch for some external monitors: DDC brightness control could work while frame capture never matched the intended output, which prevented the adaptive predictor from learning or applying brightness changes correctly.

The direct DDC path can also be unreliable on some monitors, producing errors such as invalid DDC/CI length or Expected DDC/CI length bit even when the standalone ddcutil CLI can still read or set brightness. Those failures can make wluma skip the display at startup or repeatedly fail brightness reads during normal operation.

Solution

Configuration

capture_name is now available for both output types:

• If omitted, it defaults to name.
• If set, it is passed only to the Wayland capturer.
• name remains the identifier for brightness control and predictor persistence.

Runtime behavior

• main.rs now passes name to brightness backends and capture_name to frame capture.
• The Wayland capturer logs a warning when it cannot match any compositor output.
• The DDC backend now:
  • uses slower transition and polling timings for external DDC outputs,
  • retries transient failures in the direct DDC path,
  • falls back to the ddcutil CLI when direct DDC becomes unreliable,
  • retries CLI operations and reports full command failure details when the CLI path fails.

Related Issues

• May help with [Bug]: Unable to get brightness value: DDC/CI error: invalid DDC/CI length #114 by retrying direct DDC access and falling back to the ddcutil CLI when direct DDC reads or writes fail.
• May partially address [Bug]: Unable to setup DDC/CI monitor right after startup wayland session. #160 for startup-time transient DDC/CI failures, as long as the ddcutil CLI can detect and read the monitor after direct DDC fails.

Validation

Automated:

• nix develop -c cargo fmt --check
• nix develop -c cargo test
  • Result: 37 passed
• nix develop -c cargo clippy --all-targets -- -D warnings

Manual:

• Verified that the external monitor can be matched through Wayland using capture_name.
• Verified that DDC fallback can switch from direct access to ddcutil CLI on unstable monitors.
• Verified that the adaptive controller starts learning entries for the external output once capture matching succeeds.

Risks And Follow-Ups

• CLI fallback still depends on ddcutil being installed and available in PATH.
• If neither direct DDC nor the ddcutil CLI can detect/read a monitor during startup, wluma will still skip that output.
• CLI mode is intentionally slower than direct DDC mode to reduce transient bus errors.

[max-baz]

This is awesome, thank you so much for your work! I have only a single request to swap the meaning of the newly introduced field (see the comment), I think it will help the existing users. Other than that, happy to merge and cut a release!

[max-baz]

Thank you, this is very nice now, I'm sure quite a number of users will be very happy with your contribution!
I want to push some minor documentation/logging-related changes and then merge 👍