Failed to communicate with display / Feature request: Silent retry

[nahoj]

Sometimes, especially when I change a value several times in quick succession, I'll get this error window:

Set value: Failed to communicate with display BenQ_LCD:WAL05130019
Monitor appears to be switched off or disconnected.
setvcp 10 67 --edid 00ffffffffffff0009d11b80455400002c1e010380351e78260cd5a9554ca1250d5054a56b80818081c08100a9c0b300d1c001010101565e00a0a0a02950302035000f282100001a000000ff0057414c30353133303031390a20000000fd00324c1e591b000a202020202020000000fc0042656e51204c43440a202020200138

Clicking on the Retry button typically works.

If this error couldn't be avoided, it would be nice if the tool retried automatically without opening the error window.

[digitaltrails]

This kind of problem can be reduced by increasing the Settings-Dialog sleep multiplier for the relevant VDU.

But this may be a bigger problem after the rollout of ddcutil 2.0. Ddcutil 2.0 will default to dynamically optimising each VDU's sleep multiplier. Each VDU's sleep multiplier will be much closer to it's tolerable limit, potentially dipping below it at times. So it's worth considering what can be done inside vdu_controls. I've been considering what should be done, but was waiting for ddcutil 2.0 features to stabilise.

Vdu_controls already automatically tries three times on getvcp. Because it's possible to enable just about any VCP code supported by ddcutil, I thought it might not be safe/sensible to repeat all setvcp's (it's probably harmless, but I can't be sure about it). Hence, vdu__controls asks the user.

It's going to be safe to repeat certain known setvcp's, such as brightness and contrast. I'll look at coding in some vcp-code awareness and doing retries if it's definitely safe.

Another thing I've been meaning to look at is whether throttling exec's of ddcutil might help in such situations. I've seen the odd situation where a monitor becomes unresponsive for an extended period (like 30 seconds or so). I'm not sure why, I wonder if I'm oversaturating the bus or causing the Linux/Nvidia drivers some grief. Within vdu_controls, execs of ddcutil are managed by a lock (only one call at a time so as not to saturate the i2c bus). Within the lock section I could implement a pause after an error. *[edit - I do pause 2 seconds on error, so that's already covered, but I might tweak the sleep times, say 0.25 seconds attempt_count]**

Changing to DisplayPort may reduce the incidence of failures. Nvidia's implementation of DDC isn't as reliable as AMD's, that may also increase failures. With the latest Nvidia 5xx driver, DDC doesn't work for DVI connections, only for DisplayPort. I'm stuck on 525 for now.

[digitaltrails]

I pushed a change: for setvcp failures, for vcp-codes known to be safe to retry, silently retry setvcp for up to 4 attempts.

Vcp-codes that 'are known to be safe' are those vdu_controls officially supports, except for those that make VDU config changes such as power-mode or input-source. Ddcutil supports a wider range of vcp-codes, which can be enabled in vdu_controls via Settings->enable-vcp-codes, any of these codes are considered unsafe.

Because this may happen more often after ddcutil 2.0, I've changed the sleep to 0.25 * attempt_count. The previous choice of flat 2 seconds per attempt was arbitrary (I think/I hope).

I'm going to try that with ddcutil 2.0 for a few days and see how that goes.

The error logging may be a bit chatty, I might turn that off once I'm happy with things.