Fix dimmable LED off-state, topic names, PWM flicker, brightness update outside kDefault, indefinite blinking, and blinking reliability

[thatcomputerguy0101]

Description

This fixes a few problems with controlling dimmable LEDs.

• The dimmable led code did not recognize the off state, so it was always on. A new condition was added to fix this.
• The C++ photonlib library was using the wrong topic names for ledMode (bug in Robustify setting pipeline index #790), preventing the state from being synchronized.
• The LL2+ hardwareConfig.json had its PWM frequency set too high for an RPi to achieve, causing timing imprecision resulting in LED flicker.
• The LL2+ and LL3 images did not have hardware PWM enabled; the software PWM fallback caused timing imprecision resulting in LED flicker.
• Brightness change updates from the slider would get suppressed while the current LED mode was not kDefault. The output state is now tracked separately so that brightness updates can be correctly applied.
• Blinking indefinitely with -1 blinks wasn't implemented, now it is.
• Blinking was rewritten to utilize the tracked state to prevent desynchronization

Tested on a LL2+ and LL3, LED control works as expected (NT updates work, brightness changes work, brightness is not flickery) once combined with photon-image-modifier#124.

Closes #2335

known issues

• Changing a pipeline type does not update certain properties like ledMode, which can be confusing. The workaround is to create a new pipeline.
• Using ./gradlew deploy sometimes desyncs GPIO/task ownership, resulting in some pins being somewhat uncontrollable by the new PhotonVision task. This does not seem to be a problem reproducible with Restart Software or Reboot Device. The behavior of this was very inconsistent, so it might be a race condition between releasing resources and the service shutting down.

Meta

Merge checklist:

• Pull Request title is short, imperative summary of proposed changes
• The description documents the what and why, including events that led to this PR
• If this PR changes behavior or adds a feature, user documentation is updated
• If this PR touches photon-serde, all messages have been regenerated and hashes have not changed unexpectedly
• If this PR touches configuration, this is backwards compatible with all settings going back to the previous seasons's last release (seasons end after champs ends)
• If this PR touches pipeline settings or anything related to data exchange, the frontend typing is updated
• If this PR addresses a bug, a regression test for it is added

[thatcomputerguy0101]

This works as expected on a LL2+ now, with additional image changes to enable hardware PWM (otherwise the brightness is flickery since PV doesn't leave room for consistent software PWM).

[frcwildfire8151]

We can confirm this works, but Limelight 2+ still flickers when brightness isn't set to 0% or 100%.

[frcwildfire8151]

Tried flashing Limelight 2 image and uploading this Limelight 2+ hardware config, it still flickers when brightness isn't set to 0% or 100%.

[thatcomputerguy0101]

See my previous message for an explanation of why.

[thatcomputerguy0101]

Once combined with photon-image-modifier#124, this fixes all of the problems I identified with illumination LED control on a LL2+

[mcm001]

Let's cut an image tag, and incorporate that in this PR?

[mcm001]

I cut https://github.com/PhotonVision/photon-image-modifier/releases/tag/v2026.1.2

[mcm001]

Happy with this code, but I'd like us to see how we can get any sort of test coverage of VisionLED.java in the future.

[thatcomputerguy0101]

There are still two outstanding problems that I noticed in my most recent round of testing, which may both be outside of the scope of this PR.

• Changing a pipeline type does not update certain properties like ledMode, which can be confusing. The workaround is to create a new pipeline.
• Using ./gradlew deploy sometimes desyncs GPIO/task ownership, resulting in some pins being somewhat uncontrollable by the new PhotonVision task. This does not seem to be a problem reproducible with Restart Software or Reboot Device. The behavior of this was very inconsistent, so it might be a race condition between releasing resources and the service shutting down.

Chatted in Discord