(This seems unrelated to the known issues caused by the ViGEmBus' driver "OutRep flags" limitation and more like an actual issue with how DS4Windows manages lightbar effects)
Bug description
When the "Flash Lightbar at High latency" option is enabled the lightbar is supposed to blink in a red color when the controller's input delay goes above a pre-configured limit, then to revert to the previous active color after the delay returns to below the limit.
If the Lightbar is in Passthru mode and the "red blinking" input delay warning gets activated, the lightbar will properly blink in red while the delay is high, but will then fail to properly "reset" after the warning gets deactivate:
- After the latency warning is over, it will always reset to the profile's hidden "main color" and it remain blinking
- The color gets reset to the profile's "main color" regardless if a different color was previously defined by a game or app through the passthru function
- It will only stop blinking/properly reset after a new lightbar command is sent to the controller
Reproducing the bug
Steam will be used in the example to set the lightbar color via the passthru function:
- On the used DS4Windows' profile
- Set profile's normal lightbar color to "Blue", then change its mode to "passthru"
- Set the virtual controller to DualShock 4
- Activate the high latency warning option in DS4Windows' settings
- Run DS4Windows under a custom .exe name so its virtual DS4 controllers can be detected by it
- On Steam controller settings:
- Activate "PlayStation Configuration Support"
- Make Steam change the controller's lightbar to "Green"
- Cause a latency spike so the high latency warning gets activated
What is the correct behavior
Lightbar should blink in red while the input delay is above the limit, then return to the solid green color set by Steam once it's within the limit again
What is the actual behavior
After the input delay is within limit again the lightbar returns to the "Blue" color and will remain blinking. After some time, Steam may refresh the lightbar color and only then the lightbar will properly reset
(This seems unrelated to the known issues caused by the ViGEmBus' driver "OutRep flags" limitation and more like an actual issue with how DS4Windows manages lightbar effects)
Bug description
When the "Flash Lightbar at High latency" option is enabled the lightbar is supposed to blink in a red color when the controller's input delay goes above a pre-configured limit, then to revert to the previous active color after the delay returns to below the limit.
If the Lightbar is in Passthru mode and the "red blinking" input delay warning gets activated, the lightbar will properly blink in red while the delay is high, but will then fail to properly "reset" after the warning gets deactivate:
Reproducing the bug
Steam will be used in the example to set the lightbar color via the passthru function:
What is the correct behavior
Lightbar should blink in red while the input delay is above the limit, then return to the solid green color set by Steam once it's within the limit again
What is the actual behavior
After the input delay is within limit again the lightbar returns to the "Blue" color and will remain blinking. After some time, Steam may refresh the lightbar color and only then the lightbar will properly reset