dccutil 2.0 regression, sporadic errors (Display not found, unsupported feature code) about ddcutil HOT 27 OPEN

The intermittent communication errors suggest to me that there may be a problem with the new dynamic sleep algorithm. What happens if you run with option --disable-dynamic-sleep?

Secondarily, I suspect that the phantom display problem arises because because of something unexpected in /sys.
As a first step, please execute ddcutil environment --verbose and submit the output as an attachment.

Thank you!

from ddcutil.

The intermittent communication errors suggest to me that there may be a problem with the new dynamic sleep algorithm. What happens if you run with option --disable-dynamic-sleep?

That does seem to fix the reliability issues.

Secondarily, I suspect that the phantom display problem arises because because of something unexpected in /sys. As a first step, please execute ddcutil environment --verbose and submit the output as an attachment.

Here you go: https://gist.github.com/fabian-thomas/3a4b5664a14fd75aea757f45e636dc15
There is one with --disable-dynamic-sleep and one without. The one without dynamic sleep got executed while brightness readings were unreliable.
But I did not see any phantom displays yet again. So maybe this is a non-issue. At least it is for me. But I can report back and create another environment file if they are back.

from ddcutil.

@fabian-thomas, @akdevservices

Debugging these intermittent failures remotely is likely going to be a pain, but let's give it a go.

Please invoke ddcutil with options --istats and ---enable-dynamic-sleep. Immediately after issuing a command that fails with what seems to be dynamic sleep errors, please send the following:

• the command output
• a copy of file $HOME/.cache/ddcutil/dsa

Thank you.

from ddcutil.

@fabian-thomas Re the phantom display issues:

• What is the model of your hub?
• "/sys/devices/pci0000:00/0000:00:02.0/edid" is a malformed sysfs node name. Please execute with option --trcfunc is_phantom_display and when you see that error message send me the output. Thanks.

from ddcutil.

For the first:
https://gist.github.com/fabian-thomas/27d9a81d819d9648d6ebf735e879e4d2

I used:
ddcutil getvcp 10 --display 1 --istats --enable-dynamic-sleep > istats
Stderr was: Display not found

from ddcutil.

For the second:

• It should be this one here. I hope that's what you meant.
• The phantom display is there again:
  ddcutil detect --trcfunc is_phantom_display > out gives: https://gist.github.com/fabian-thomas/24225c2e62e807f6fc475474741a4cef

from ddcutil.

I came up with an idea where this phantom display may come from, but I don't know much about the Linux display/dev stack, so it might be that this makes absolutely no sense:
I occassionally run both xorg and wayland at the same time, also today. I saw that wayland creates new devices for the same monitor. Maybe the phantom displays appear for that reason?

from ddcutil.

The phantom displays is a device driver issue. The problem is that for one of the displays connected to the dock, it appears as both a /dev/i2c device on the dock and on the laptop port to which the dock is connected.

See this bug report for an explanation by one of the i915 developers of why this happens and why it's hard to fix.

from ddcutil.

Thanks for looking that up. I'm happy that this is only a cosmetic problem for me 😅

from ddcutil.

@fabian-thomas , @akdevservices Branch 2.0.2-dev contains changes to resolve or at least further diagnose the problems reported in this issue.

I suspect that the intermittent failures are the result of interaction between the dynamic sleep algorithm and existing special handling of the DDC Null Response, which some monitors abuse as a way to indicate an unsupported feature. As a first step, message "Maximum retries ... for DDC Null Response exceeded" is written to the terminal and the system log if the number of retries has been reduced for DDC Null Response. Do you see this message along with the intermittent failures?

As for phantom displays, the algorithm was changed for release 2.0, so I would expect to see more displays reported as phantom. The one problem I saw in your output is the valid display was numbered 2 instead of 1. This should now be corrected.

from ddcutil.

Sorry for letting this wait so long. Forgot to do this on the weekend. I've now build from 2.0.2-dev and it seems like the detection is completely broken now. At least my monitor is not recognized anymore by ddcutil detect. Also with ddcutil detect --disable-dynamic-sleep.

from ddcutil.

Development option --f7 disables phantom display detection. Please submit the output of ddcutil detect --verbose ---disable-dynamic-sleep and ddcutil detect --verbose --disable-dynamic-sleep --f7. Also please submit recent entries in the system log. (Command journalctl -t ddcuti -b reports ddcutil entries for the current boot.) Thank you.

from ddcutil.

https://gist.github.com/fabian-thomas/27df948b345a57071b2506b0ff0b714c

Both outputs are identical, nevertheless I uploaded both. The journal seems to not have anything related to this detect call. Note that the errors in there come from invocations in the morning (9 am), and now its 8 pm for me.

from ddcutil.

Am I correctly inferring that ddcutil detect does not report the monitor attached to your hub?

If so, please execute ddcutil detect -v --f2 and submit the output as an attachment. Thank you.

from ddcutil.

Yes, the docked monitor is never detected with the dev branch. Here is the output:
https://gist.github.com/fabian-thomas/c17fc52795957ed2144e35c18de3250b

from ddcutil.

I just pushed extensive changes to branch 2.0.2-dev. Please run your tests again against the updated 2.0.2-dev branch.

If errors persist, please execute ddcutil detect --verbose --f2 --trace ddc --trace ddcio --trace i2c. The amount of output will be insane, but hopefully I can find the needle in the haystack. What I can see is that the i915 driver is not using /sys in the way I would expect based on information from the i915 driver folks, but ddcutil should have been able to cope with that.

Thank you for your help diagnosing the bugs you've reported. Once this issue is resolved I should be able to push a 2.0.2 release, or at least a release candidate.

from ddcutil.

It looks like you haven't pushed your changes. At least I can't fetch them. 😅

from ddcutil.

My bad. Done.

from ddcutil.

Ok, so now I tried again with the old commit (a9a4ea1) and weirdly now everything works perfectly fine. That means, both detect and getvcp. Also, I see no phantom display anymore. I can't explain why. So currently everything is as stable as with ddcutil 1.

I did hibernate in between, but I've probably done that between the other two invocations too. Maybe unplugging the dock fixed something, but I've probably done that too before.

Here is the output with latest dev:
https://gist.github.com/fabian-thomas/51f146fc0fb498b24d90df9140e55f5b

It also seems to work perfectly fine.

from ddcutil.

Thank you for the quick test. Do keep me posted. If you encounter problems again, the output with just trace class DDC should be sufficient, i.e. ddcutil detect --verbose --f2 --trace ddc

from ddcutil.

Weird, the problems are back this morning, after hibernating yesterday. Cant find the display in ddc detect.

Here are the logs with commit 71a6d25:
https://gist.github.com/fabian-thomas/e7f6e7535bb5f924a142b2116f87213e

from ddcutil.

Reading the EDID is failing. This can be seen at approx line 677 and following, function i2c_get_raw_edid_by_fd() and i2c_get_edid_bytes_directly_using_ioctl(). There appears be a problem with your dock/hibernation/driver i915.

At first glance, I don't see any difference between the code for these functions between 1.4.1 and 2.0.2-dev, but I believe you when you say you didn't see the problem in 1.4.1. When the problem occurs, what do you get when you execute ddcutil detect --verbose --f2 --trace i2c?

from ddcutil.

Also, when you hit the bug, what does get-edid -b 10|parse-edid show?

from ddcutil.

It seems like above logs already included one with i2c tracing enabled. Nevertheless, here are more logs:
https://gist.github.com/fabian-thomas/c56491c16598f98967054a5f1a39dbb7

It looks like get-edid works perfectly fine, while ddcutil fails when reading the edid. Should I try to bisect this issue with git-bisect?

from ddcutil.