DDC/CI communication with monitors can be unreliable,especially when the monitor is still in the process offully waking up. The moment that we receive a connectionor DPMS awake event may not be the moment that brightnesscommands start working.
Prior to this commit, DDCutilDisplay protected itself againstthis case with a drastic measure: if a read or write commandfailed, the object would claim brightness controls asunsupported. This error condition meant that we won't end upwith inconsistent state, but it also makes the monitor'sbrightness slider go away (or fall back to softwarebrightness controls if KWin wants those instead).
This commit still uses the same failure mode, but will tryharder before we give up on the monitor altogether.Both initialization (reading the initial brightness value)and setBrightness() will now retry a few times if thefirst attempt didn't work out. Subsequent retries will bespaced 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 whilethey're waiting for another initialization attempt.
setBrightness() will only be performed once initializationhas succeeded, so the two operations are mutually exclusive.We can reuse DDCutilDisplay's existing brightness delay timerfor both kinds of retry operations.
Hoping for reviews from @littlesweet and @zamundaaa (but anyone, feel free to test & review).