Open ASong5 opened 6 months ago
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.
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.
Forgot to mention the version of ddcutil I'm using..
2.15-dev
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.
OS: Ubuntu Noble Numbat (development branch) x86_64 Kernel: 6.8.0-11-generic Uptime: 4 hours, 21 mins Packages: 3251 (dpkg), 44 (flatpak), 8 (snap) Shell: bash 5.2.21 Resolution: 1920x1080 WM: kwin WM Theme: Bismuth Theme: Breeze [GTK2/3] Icons: candy-icons [GTK2/3] Terminal: tmux CPU: AMD Ryzen 5 3600 (12) @ 3.600GHz GPU: AMD ATI Radeon RX 5600 OEM/5600 XT / 5700/5700 XT Memory: 5411MiB / 15908MiB
I have a simple script that switches monitor input using ddcutil:
It works when switching to HDMI, but when I try to switch to DP the PC seems to hang (might be just the display freezing) for around 10 seconds and fails to switch (simple reverts back to HDMI). This happens about half the time, but works fine the other half. I'm sure there's a more specific way to deduce why it happens, but that's beyond my level of knowledge. I'm not sure whether it's an issue related to my window/tiling manager (KWin/Bismuth) or if it's a wayland issue, or even a driver issue.
Whenever it fails, the following entry can be found in journalctl:
Maybe the following ddcutil logs are useful:
Lastly, I noticed a lot of errors when viewing the capabilities of the monitor in question:
0x60 seems to be invalid for this monitor, which seems odd to me, because it still sometimes works. Although, it does say in the docs that the capabilities string is unreliable, so I won't make any assumptions.
Sorry for this massive info dump, I'm not very savvy when it comes to lower-level hardware things; I just wanted this little script to work so I can switch monitors easily :(
Thanks