Switching monitor input to DP with setvcp fails around half the time

[ASong5]

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:

#!/usr/bin/env bash

set -o nounset
set -o errexit

# Get current input
current=$(ddcutil -d 2 getvcp 60 | sed -n "s/.*(sl=\(.*\))/\1/p")

# Get the other input
case $current in

    0x11)
        output=0x0f
        ;;

    0x0f)
        output=0x11
        ;;

    *)
        echo "Unknown input"
        exit 1
        ;;
esac

# Set new input
ddcutil -d 2 setvcp 60 $output

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:

Mar 30 16:54:41 user-desktop plasmashell[1075335]: org.kde.plasma.containmentlayoutmanager: Trying to take space not available BasicAppletContainer_QMLTYPE_57_QML_70(0x5dc90e1cedd0, par│
│Mar 30 16:54:41 user-desktop plasmashell[1075444]: QObject::connect: No such slot DesktopProtocol::_k_slotRedirection(KIO::Job *, QUrl)                                                  │
│Mar 30 16:54:41 user-desktop kwin_wayland_wrapper[1809]: org.kde.bismuth: Window becomes unmanaged and gets removed :( The client was KWin::XdgToplevelWindow(0x60461647e640)            │

Maybe the following ddcutil logs are useful:

> ddcutil -d 2 setvcp 60 0x0f --ddcdata --stats all --syslog verbose

DDC: Unexpected source address 0x02, should be 0x6e
DDC: i2c_response_bytes: 02 00 ff ff 02 02 6b 29 6d 73 77 68 71 6c 28 31 29 29 00 d8 65 70 28 36 34 29 6d 70 51 82 01 10 ac 6e 88 02 00 10 00 00
DDC: Unexpected source address 0x00, should be 0x6e
DDC: i2c_response_bytes: 00 00 00 64 00 64 a4 29 6d 73 77 68 71 6c 28 31 29 29 00 d8 65 70 28 36 34 29 6d 70 51 82 01 dd 61 00 00 64 00 64 a4 29
DDC: Unexpected source address 0x00, should be 0x6e
DDC: i2c_response_bytes: 00 00 ff ff 00 00 68 29 6d 73 77 68 71 6c 28 31 29 29 00 d8 65 70 28 36 34 29 6d 70 51 82 01 df 63 00 ff ff 00 00 68 29
DDC: Actual checksum 0x63, expected 0x62
DDC: i2c_response_bytes: 6e 82 01 df 63 00 ff ff 00 00 68 29 6d 73 77 68 71 6c 28 31 29 29 00 d8 65 70 28 36 34 29 6d 70 6e 82 01 df 63 00 ff ff
DDC: Unexpected VCP opcode 0xdd, should be 0xdf, response data bytes: 0201dd00 00ff0000

EXECUTION STATISTICS

Maxtries Settings:
Operation Type                    Current  Default     Min     Max
Write only exchange tries:              4        4       4       4
Write read exchange tries:             10        4      10      10
Multi-part read exchange tries:         8        4       8       8
Multi-part_write exchange tries:        8        4       8       8


Retry statistics for write only
   Max tries allowed: 4
   Successful attempts by number of tries required:
       1:    1
   Total successful attempts:          1
   Failed due to max tries exceeded:   0
   Failed due to fatal error:          0
   Total attempts:                     1

Retry statistics for write-read
   Max tries allowed: 10
   Successful attempts by number of tries required:
       1:    2
       2:    3
       3:    1
   Total successful attempts:          6
   Failed due to max tries exceeded:   0
   Failed due to fatal error:          0
   Total attempts:                     6

Retry statistics for multi-part read
   No tries attempted

Retry statistics for multi-part write
   No tries attempted

DDC Related Errors:

Count   Status Code                          Description
    5   DDCRC_DDC_DATA               (-3001) DDC data error
Total errors: 5

Errors Wrapped in Retry:

Count   Status Code                          Description
    5   DDCRC_DDC_DATA               (-3001) DDC data error
Total errors: 5


IO and Sleep Events:
   Total IO events:         79
   IO error count:           5
   Total sleep events:      23

   Sleep Event type      Count
   SE_WRITE_TO_READ             11
   SE_POST_WRITE                 1
   SE_POST_READ                 11
   SE_POST_SAVE_SETTINGS         0
   SE_PRE_MULTI_PART_READ        0
   SE_POST_CAP_TABLE_SEGMENT     0
   SE_SPECIAL                    0

Call Stats:
   Type                                     Count    Millisec  (      Nanosec)
   i2c writes using ioctl (I2_IOCTL_WRITE)     41         248  (    248055970)
   i2c reads using ioctl  (I2_IOCTL_READ)      18         230  (    230213481)
   open file calls        (IE_OPEN)            10           0  (        46140)
   close file calls       (IE_CLOSE)           10           0  (        23530)
   Totals:                                     79         478  (    478339121)

Sleep Call Stats:
   Total sleep calls:                                      11
   Requested sleep time milliseconds :                     76
   Actual sleep milliseconds (nanosec):                    76  (     76644536)

Total elapsed milliseconds (nanoseconds):                 643  (    643127762)

Total non sleep system call time:        478 milliseconds
Total sleep call time:                    76 milliseconds
Elapsed time:       

Lastly, I noticed a lot of errors when viewing the capabilities of the monitor in question:

ddcutil -d 2 capabilities --verbose
Feature definition file not found: AOC-24G1WG3_-9217.mccs
Read cached capabilities string from /home/pundrew/.cache/ddcutil/capabilities
Unparsed capabilities string: (prot(monitor)type(lcd)model(C24G2)cmds(010203070C4EF3E3)vcp(020405080B0C101214(010506080B)16181A6C6E70ACAEB6C0C6C8C9CA60(010F1112)CC(0102030405060708090A0B0D1214161E)D6(0104)DFDC(000B0C0D0E0F10)86(0205)628D(0102)FF)mswhql(1)asset_eep(40)mccs_ver(2.2))
Errors parsing capabilities string:
   Error processing commands list: 010203070C4EF3E3
   Invalid VCP value in list for feature x14: 010506080B
   Invalid VCP value in list for feature x60: 010F1112
   Invalid VCP value in list for feature xcc: 0102030405060708090A0B0D1214161E
   Invalid VCP value in list for feature xd6: 0104
   Invalid VCP value in list for feature xdc: 000B0C0D0E0F10
   Invalid VCP value in list for feature x86: 0205
   Invalid VCP value in list for feature x8d: 0102
Model: C24G2
MCCS version: 2.2
VCP Features:
   Feature: 02 (New control value)
   Feature: 04 (Restore factory defaults)
   Feature: 05 (Restore factory brightness/contrast defaults)
   Feature: 08 (Restore color defaults)
   Feature: 0B (Color temperature increment)
   Feature: 0C (Color temperature request)
   Feature: 10 (Brightness)
   Feature: 12 (Contrast)
   Feature: 14 (Select color preset)
      Values (unparsed): 010506080B
      Values (  parsed):
   Feature: 16 (Video gain: Red)
   Feature: 18 (Video gain: Green)
   Feature: 1A (Video gain: Blue)
   Feature: 6C (Video black level: Red)
   Feature: 6E (Video black level: Green)
   Feature: 70 (Video black level: Blue)
   Feature: AC (Horizontal frequency)
   Feature: AE (Vertical frequency)
   Feature: B6 (Display technology type)
   Feature: C0 (Display usage time)
   Feature: C6 (Application enable key)
   Feature: C8 (Display controller type)
   Feature: C9 (Display firmware level)
   Feature: CA (OSD)
   Feature: 60 (Input Source)
      Values (unparsed): 010F1112
      Values (  parsed):
   Feature: CC (OSD Language)
      Values (unparsed): 0102030405060708090A0B0D1214161E
      Values (  parsed):
   Feature: D6 (Power mode)
      Values (unparsed): 0104
      Values (  parsed):
   Feature: DF (VCP Version)
   Feature: DC (Display Mode)
      Values (unparsed): 000B0C0D0E0F10
      Values (  parsed):
   Feature: 86 (Display Scaling)
      Values (unparsed): 0205
      Values (  parsed):
   Feature: 62 (Audio speaker volume)
   Feature: 8D (Audio Mute)
      Values (unparsed): 0102
      Values (  parsed): d'Y (interpretation unavailable)
   Feature: FF (Manufacturer specific feature)

Capabilities string not completely parsed
   Errors:
      Error processing commands list: 010203070C4EF3E3
      Invalid VCP value in list for feature x14: 010506080B
      Invalid VCP value in list for feature x60: 010F1112
      Invalid VCP value in list for feature xcc: 0102030405060708090A0B0D1214161E
      Invalid VCP value in list for feature xd6: 0104
      Invalid VCP value in list for feature xdc: 000B0C0D0E0F10
      Invalid VCP value in list for feature x86: 0205
      Invalid VCP value in list for feature x8d: 0102

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

[rockowitz]

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.

[ASong5]

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.

[ASong5]

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

2.15-dev

[rockowitz]

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.