(cherry-pick) daemon: Retry failed DDC/CI reads and writes repeatedly
Cherry-pick MR for !441 (merged).
DDC/CI communication with monitors can be unreliable, especially when the monitor is still in the process of fully waking up. The moment that we receive a connection or DPMS awake event may not be the moment that brightness commands start working.
Prior to this commit, DDCutilDisplay protected itself against
this case with a drastic measure: if a read or write command
failed, the object would claim brightness controls as
unsupported. This error condition meant that we won't end up
with inconsistent state, but it also makes the monitor's
brightness slider go away (or fall back to software
brightness controls if KWin wants those instead).
This commit still uses the same failure mode, but will try
harder before we give up on the monitor altogether.
Both initialization (reading the initial brightness value)
and setBrightness() will now retry a few times if the
first attempt didn't work out. Subsequent retries will be
spaced out further, until we finally give up on that monitor.
To avoid exposing uninitialized DDCutilDisplay objects,
a list of pending displays now holds these objects while
they're waiting for another initialization attempt.
setBrightness() will only be performed once initialization
has succeeded, so the two operations are mutually exclusive.
We can reuse DDCutilDisplay's existing brightness delay timer
for both kinds of retry operations.
(cherry picked from commit 44e6922a)
Co-authored-by: Jakob Petsovits jpetso@petsovits.com