Switching monitor input to DP with setvcp fails around half the time about ddcutil HOT 4 OPEN

What release of ddcutil are you using? In general, please submit the output of ddcutil innterrogate with bug reports - it answers this and innumerable other questions.

There are several things to note.

There are many data errors. You also appear to be using a low sleep-multiplier value: avg-sleep-time-per-call = 82/14 = 5.9. Since almost all sleep times in the spec are 40-50 ms, this suggests a sleep-multiplier in the range of around .12, which is low. Try using an explicit --sleep-multiplier value, e.g. 1.0, and see if that reduces the data errors.

With getvcp, ddcutil sends a request packet and receives a reply packet. The reply packet indicates whether the request was successfully processed. With setvcp, there's only a request packet. The status code from sending the request packet only indicates whether the request was successfully delivered, not whether the monitor successfully acted on the request.

For most features, setvcp makes an implicit getvcp call to verify that the monitor reports the expected new value. Because it changes the input source, feature x60 is one of a few for which this check does not occur. You might want to try explicitly calling getvcp after setvcp to verify that the expected value is set and, if not, retry setvcp.

Apparently you have two monitors, one on a HDMI connector and one on DP. So when switching to HDMI you are on the DP connector, and when switching to DP you are on the HDMI connector. It's not uncommon for DP communication to be reliable with a shorter sleep-multiplier time than HDMI.

Finally the capabilities string reported by the monitor is not in the expected form - it contains no spaces, which is why the capabilities command is failing. However, because the capabilities string returned from monitors is generally unreliable the capabilities command is purely informational. ddcutil does not rely on it when performing getvcp and setvcp operations. I will look into making the parsing of capabilities strings more lenient.

from ddcutil.

ddcutil_interrogate.log

Hey thanks for the response.

I took your advice and used an explicit sleep multiplier of 1.0, but that didn't seem to change anything (at least with respect to the observable problem at hand). I attached the ddcutil interrogate log above, and it seems to seg fault once it gets to the display port. I noticed in the docs there is an option to use dynamic sleep, do you think that would be helpful in any capacity, or is that not relevant to this issue?

I also did what you suggested and added a getvcp call after setvcp; when it fails, it outputs "No Display Found". So I simply threw them in a retry loop. This technically works as it eventually switches successfully, but the underlying issue that's causing the long hang/freezes when switching to DP is obviously not fixed. It takes upwards of 20 seconds sometimes to successfully switch (if you account for the hangs in between retries), which is not ideal..

Again, sorry I'm not able to provide anymore meaningful insight with regard to the problem - most of this stuff is way out of my depth. If there are any more logs I could provide to make this easier to troubleshoot please let me know.

Thanks again.

from ddcutil.

Forgot to mention the version of ddcutil I'm using..

2.15-dev

from ddcutil.

I'm afraid that this is the sort of problem that's difficult diagnose remotely. Clearly it reflects your specific hardware.

I do, however, have a few comments that may be of help.

Have you verified that both monitors actually use the documented values for feature x60. Some do not. Try setting the input sources manually using the OSD and use getvcp to see what values the monitors are actually using. Also, bear in mind that some monitors respond properly to getvcp requests only if that request is made on the currently active input; others will respond properly on any input.

The DDC data errors you reported are commonly the result of the sleep-multiplier being set too low. You might even try making even longer, e.g. --sleep-muliplier 2.0. Dynamic sleep adjustment is enabled by default, which would explain why the observed sleep-muliplier is so low in your initial reports. For diagnostic purposes, it's better to disable it completely: --disable-dynamic-sleep. Finally, in this regard, when testing always use option --ddcdata to report DDC data errors.

As best I can tell your AOC monitor has only a HDMI connector, not a DP connector, so you are using some kind of DP->HDMI adapter. Is that correct? This could be a source of errors. See the discussion of DP->HDMI connection here. If using a passive connector you might try switching to an active connector, and vice versa.

Finally, please run interrogate under valgrind if you can: valgrind ddcutil interrogate. This will precisely locate the segfault. The DRM Connector State report where the failure occurs is for some new functionality. It has no relation to the problem you are having.

from ddcutil.