New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ddcutil 2.0 regression. (Invalid Display. DDC communication failed. causes: EIO / ETIMEDOUT). works in 1.4.1-1 #358
Comments
I reconfigured the system I'm on now to use a DVI to DP adapter instead of plugging a DVI monitor directly into the DVI output on my RX580. I wasn't able to recreate your problem on ddcutil 2.0.0, but I did trigger similar errors on 2.0.2-dev. The problem seems to be related to aggressive parallelization in display detection and attempting to avoid explicitly reading the EDID by obtaining it from /sys. If you can, please build from branch 2.0.2-dev. If the problem does not resolve, try disabling dynamic the dynamic sleep adjustment (--disable-dynamic-sleep) and disabling parallel DDC checks (--ddc-check-async-threshold 9). On the other hand, if no problems are encountered, try either or both of the following: hidden option --i2c-bus-check-async-threshold 1 turns on parallel checking for EDIDs, and hidden utility option --f14 enables reading the EDID from /sys. Thanks. |
2.0.2-dev detect without arguments works partially. at least the double detected display is gone. ddcutil detect
with arguments seems to make things better as well but now its "detection failed": ddcutil detect --disable-dynamic-sleep --ddc-check-async-threshold 9
I was just going to test edit tried again: ddcutil detect --i2c-bus-check-async-threshold 1
ddcutil detect --f14
ddcutil detect --f14 --i2c-bus-check-async-threshold 1
do you need |
There are several things going on here. First, attempting to read the EDID in parallel from all /dev/i2c devices can sometimes, but not always fail. Reading the EDID from /sys (using --f14) avoids this problem, but can encounter obscure error in the EDID that amdgpu writes to sys, which I was hoping to avoid. For now, the default is --disable-i2c-bus-check-async_threshold. Have you tried setting a high fixed sleep-multiplier, e.g. --sleep-multiplier 2.0 --disable-dynamic-sleep. That Samsung monitor is rather old, and its DDC implementation may be marginal. Have you tried another monitor in the DP-3 slot? And do you know if your DP-DVI cable/adapter is active or passive? |
sorry for the late reply. busy days.
i'm not at home until new year so i can't do further testing. will update here as soon i can. I would like to thank you for the fast and friendly communication so far and wish you a happy new year! |
I think i can can close this. The monitor in question got replaced now and the new gets detected perfect. so I'll file this under strange quirk of this specific device. |
I am having the same issue with my LG OLED 4k C3 tv :ddcutil detect Display 1 |
@Matt-1-2-3 Please ensure you are running the new release 2.1.2? Then submit the output of ddcutil interrogate |
I am attaching the output of interrogate as a text file. It's long and my user name was replaced with "myuser" and hostname with "myhost" ddcutil --version |
The output of command i2cdetect -y 5 on line 631 shows that while slave address x50 (EDID) is responsive, slave address x37 (DDC) is not. So whatever problem you're having is outside of ddcutil's control. I see that you're running on a Zen kernel. I suggest you try using a stock kernel. If the problem resolves, i.e. i2cdetect reports slave address x37 as responsive, the problem is an issue for the Zen developers. |
Ill reboot and try stock kernel |
Unfortunately stock kernel with the same results, new log uploaded |
The i2cdetect output in the interrogate log is unchanged. I don't see why it would show anything different, but for absolute certainty try running i2cdetect directly from the terminal, outside of ddcutil. |
from the cli itself me@pc[~]:i2cdetect -y 5 |
ddcutil detect
on 1.4.1-1 works fine:interrogate.txt
but 2.0.0-1 gives me this:
interrogate2.txt
which then breaks all tools that rely on correct detection.
this is on Arch Linux. The monitor is connected via DVI to DP adapter. I will be happy to help you obtain all the necessary information and carry out all the necessary tests.
The text was updated successfully, but these errors were encountered: