rockowitz
ddcutil stopped working with --skip-ddc-checks option
Hey, for some reason anytime I run a command with the --skip-ddc-checks option, I get the error "Maximum retries exceeded", while it works without that option. It worked before (like 10 minutes ago). I started including it in some test runs to try and speed up the execution and it majorly reduced the time it took to switch my monitors input source. I'd like to get it fixed because it took multiple seconds to switch before
btw this is the script I plan to use it in (python):
import subprocess
possible = ["x11", "x12"]
current = subprocess.run(["ddcutil", "getvcp", "60", "--terse", "--noverify", "--skip-ddc-checks", "--mccs", "2.1"], stdout=subprocess.PIPE).stdout.decode('utf-8')
print(current)
current = current.split(" ")
current = current[len(current) - 1].replace("\n", "")
try:
print(current)
index = possible.index(current)
except ValueError:
print("NOPE")
else:
if index + 1 >= len(possible):
index = 0
else:
index += 1
subprocess.run(["ddcutil", "setvcp", "60", "0" + possible[index], "--noverify", "--skip-ddc-checks", "--mccs", "2.1"])
Fascinating problem. I have no idea what's going on, but do have a few suggestions for next steps.
A slightly modified version of your program runs with no problem on my workstation here, so the problem would seem to be specific to your system. What is your hardware configuration (processor, video card, monitors)? Better yet, submit the output of interrogate (as an attachment of some sort).
Do the errors occur on the getvcp command or setvcp?
Use options --ddcdata --stats to get more detailed information about the failures. Submit the output.
Use option --sleep-multiplier to explicitly set the sleep multiplier. Start with a very high value, e.g. 2.0. If that resolves the problem reduce the value used until you see failures.
If the failures are on setvcp, try inserting a sleep between the getvcp and setvcp calls.
Lastly, option --mccs 2.1 is irrelevant. It applies only to how getvcp output is interpreted. Since you are using option --terse , getvcp just reports the raw feature value, without interpretation.
.
Output of interrogate: interrogate.txt
So, the errors occur on any command I run together with the --skip-ddc-checks argument
Running ddcutil setvcp 60 x11 --skip-ddc-checks --ddcdata --stats returns:
VCP (aka MCCS) version for display is undetected or less than 2.0. Interpretation may not be accurate.
Setting value failed for feature x60, rc=DDCRC_RETRIES(-3007): maximum retries exceeded
Try errors: DDCRC_RETRIES
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: None
Total successful attempts: 0
Failed due to max tries exceeded: 1
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: None
Total successful attempts: 0
Failed due to max tries exceeded: 1
Failed due to fatal error: 0
Total attempts: 1
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
14 EREMOTEIO ( -121) Remote I/O error
2 DDCRC_RETRIES (-3007) maximum retries exceeded (derived)
Total errors: 16
Errors Wrapped in Retry:
Count Status Code Description
10 EREMOTEIO ( -121) Remote I/O error
Total errors: 10
IO and Sleep Events:
Total IO events: 71
IO error count: 16
Total sleep events: 4
Sleep Event type Count
SE_WRITE_TO_READ 0
SE_POST_WRITE 4
SE_POST_READ 0
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) 39 341 ( 341707690)
i2c reads using ioctl (I2_IOCTL_READ) 10 168 ( 168927951)
open file calls (IE_OPEN) 11 0 ( 162552)
close file calls (IE_CLOSE) 11 0 ( 88895)
Totals: 71 510 ( 510887088)
Sleep Call Stats:
Total sleep calls: 4
Requested sleep time milliseconds : 400
Actual sleep milliseconds (nanosec): 400 ( 400451771)
Total elapsed milliseconds (nanoseconds): 1021 ( 1021785763)
Total non sleep system call time: 510 milliseconds
Total sleep call time: 400 milliseconds
Elapsed time: 1021 milliseconds
Running ddcutil setvcp 60 x11 --skip-ddc-checks --sleep-multiplier 2 returns:
VCP (aka MCCS) version for display is undetected or less than 2.0. Interpretation may not be accurate.
Setting value failed for feature x60, rc=DDCRC_RETRIES(-3007): maximum retries exceeded
Try errors: DDCRC_RETRIES
As said above, it appears on all commands
I only added --mccs 2.1 because of the VCP (aka MCCS) version for display is undetected or less than 2.0. Interpretation may not be accurate. I kept seeing on every command I ran and that annoyed me .-.
The interrogate output shows a number of issues:
- The system journal is full of use-after-free errors in the the nvidia driver. so driver operations are suspect
- You are not using the Special Nvidia Driver Settings. which are sometimes needed for reliable operation.
- You have 2 connected displays, the ASUS VG245 on connector HDMI-A2 at /dev/i2c-10, and the HP LP 2065 on connector DP-2 at dev/i2c-11. Communication always fails with the latter due to data errors.
- Consistent with this, the dynamic sleep stats file has data for /dev/i2c-10, but not /dev/i2c-11
- Per the MCCS spec, the x60 values for DP-2, HDMI-1 and HDMI-2 are x10, x11, x12 respectively. Unless your monitors are using non-standard feature values, your script switches between HDMI-1 and HDMI-2. But your monitors are on DP-2 and HDMI-2.
- The script output reports driver error EREMOTEIO when when feature value x11 is specified. But x11 is input HDMI-1, and there is no monitor on HDMI-1, so EREMOTEIO is appropriate.
Given all this, unless the interrogate output does not reflect the environment in which your script runs, I don't see how it would work even without --skip-ddc-checks..
Finally, output of the irrelevant messages re MCCS is suppressed in branch 2.2.1-rc1. I had forgotten about the fix that suppresses the messages.
If you believe it makes sense to pursue the issue further, please build ddcutil from branch 2.2.1-rc1.
I've been using the 550 driver, KDE and the 570 driver has problems with DPMS suspend. But temporarily installed the 570 driver and built 2.2.1-rc1:
inxi -bG
System:
Host: kosmos1 Kernel: 6.14.6-1-default arch: x86_64 bits: 64
Desktop: KDE Plasma v: 6.3.5 Distro: openSUSE Tumbleweed 20250515
Machine:
Type: Desktop System: ASUS product: N/A v: N/A serial: <superuser required>
Mobo: ASUSTeK model: TUF GAMING B550-PLUS WIFI II v: Rev X.0x
serial: <superuser required> UEFI: American Megatrends v: 3607
date: 03/22/2024
CPU:
Info: 6-core AMD Ryzen 5 5600 [MT MCP] speed (MHz): avg: 3600
min/max: 550/4470
Graphics:
Device-1: NVIDIA TU116 [GeForce GTX 1650 SUPER] driver: nvidia v: 570.144
Display: x11 server: X.Org v: 21.1.15 with: Xwayland v: 24.1.6 driver: X:
loaded: nvidia gpu: nvidia,nvidia-nvswitch resolution: 1: 1920x1200~60Hz
2: 3840x2160~60Hz
API: EGL v: 1.5 drivers: nouveau,nvidia,swrast
platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 570.144
renderer: NVIDIA GeForce GTX 1650 SUPER/PCIe/SSE2
API: Vulkan v: 1.4.309 drivers: N/A surfaces: xcb,xlib
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor gpu: nvidia-smi wl: wayland-info
x11: xdpyinfo, xprop, xrandr
Network:
Device-1: MEDIATEK MT7921 802.11ax PCI Express Wireless Network Adapter
driver: mt7921e
Device-2: Realtek RTL8125 2.5GbE driver: r8169
Drives:
Local Storage: total: 9.57 TiB used: 1.76 TiB (18.4%)
Info:
Memory: total: 32 GiB available: 31.25 GiB used: 10.72 GiB (34.3%)
Processes: 416 Uptime: 0h 3m Shell: Zsh inxi: 3.3.37
I also built ddcutil 2.2.1-rc1:
./src/ddcutil --display 2 --skip-ddc-checks getvcp 10
VCP (aka MCCS) version for display is undetected or less than 2.0. Interpretation may not be accurate.
VCP code 0x10 (Brightness ): current value = 87, max value = 100
./src/ddcutil --display 2 --skip-ddc-checks setvcp 10 90
Getvcp and setvp seem ok for both my displays, that's with or without --skip-ddc-checks.
I'll be reverting to 550 after typing this.
So... it works now... I added the argument -d 2 which is all I wanted because that monitor has a chromecast in the second port. I didn't realize that this argument was not in the script. So it seems like all my attempts at getting this working tried to talk to my other monitor (which is not connected over DP, it's connected to a usb hub over thunderbolt and then using a usb-c to hdmi adapter to DVI (last cable is hdmi to DVI)). I noticed that DCC doesn't work over my usb hub, and only works when I connect the monitor directly to the hdmi in my laptop. This is to be expected as I read online somewhere. So I think everything actually works as it's supposed to work?
I'm guessing that not providing the -d argument causes ddcutil to try and send the command to every monitor from 0 to n which in turn causes is to hard fail because my monitor 1 is not able to use dcc?
So, I just tried to plug the usb c to hdmi adapter directly into my laptop and it still didn't work with my other monitor (which I don't need currently but it would be a nice to have). So this makes me think it's not the usb hub as I thought before. I have this adapter and it seems to be using DP Alt mode which according to this is supposed to work?
For background, see DDC Over DisplayPort and USB-C DisplayPort Alt Mode. The USB-C to HDMI adapter is an active adapter. From the USB-C side, it's as if its communicating with a DisplayPort device. That's why the monitor is reported as DisplayPort, not HDMI or DVI.
Whether a dock properly transmits I2C signals (i.e. DDC) is a bit hit or miss, depending on the dock/driver combination. In my personal experience most do, but YMMV.
The --d option specifies the monitor to communicate with (per the display numbers reported by command detect). Displays are numbered from 1. If it is not explicitly specified, the display number defaults to 1. That's it. There's no further logic to send a command to some other monitor if the command fails.
Before you test adapters, are you sure that plugging the monitor's HDMI/DVI connector directly into a HDMI/DVI connector on your computer works? (For our purposes, DVI and HDMI are equivalent - they just have different pin assignments).
The USB-C - HDMI adapter assumes that the host on the USB-C implements DP Alt mode. It routes signals as per Alt mode. That is, the host switches the signaling on the type-C connector to alt mode, so the connector in effect becomes a DisplayPort connector. The adapter converts the DP signaling to HDMI. So yes, your adapter should work. But again, YMMV.
Yes, it does work when directly connected to my Laptop. When I do that and run ddcutil detect it lists the monitor as:
Display 1
I2C bus: /dev/i2c-10
DRM connector: card1-HDMI-A-2
EDID synopsis:
Mfg id: HWP - Hewlett Packard
Model: HP LP2065
Product code: 2674 (0x0a72)
Serial number: CNG54601VZ
Binary serial number: 16843009 (0x01010101)
Manufacture year: 2005, Week: 46
VCP version: 2.0
And when I connect it using the usb c to hdmi adapter it reports it as
Invalid display
I2C bus: /dev/i2c-12
DRM connector: card1-DP-3
EDID synopsis:
Mfg id: HWP - Hewlett Packard
Model: HP LP2065
Product code: 2674 (0x0a72)
Serial number: CNG54601VZ
Binary serial number: 16843009 (0x01010101)
Manufacture year: 2005, Week: 46
DDC communication failed. (getvcp of feature x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)])
When you connect your Asus monitor using the USB-C to HDMI adapter does it work?
With the HP monitor, what is the output of:
ddcutil detect --ddcdata
ddcutil detect --ddcdata --sleep-multiplier 2.0