No (DisplayLink) displays found on 2.1.4, but works on 2.0.0

[arthurrump]

ddcutil detect on v2.1.4 reports "No displays found." while v2.0.0 correctly reports two external displays and an invalid display for the internal laptop monitor. The external displays are connected through a DisplayLink/EVDI dock. If I connect one of them directly with HDMI, the display is recognized and brightness controls work.

Full logs of ddcutil detect and sudo ddcutil interrogate --verbose on both versions: https://gist.github.com/arthurrump/62659ae7dc2f9904bddf5ee9a7f786a0

[rockowitz]

Thank you for the report.

I'm surprised that ddcutil ever worked with DisplayLink. Last I looked at DisplayLink, which was some time ago, there was no support for DDC/CI. Apparently that has changed.

It's not clear to me what ddcutil change between 2.0.0 and 2.1.4 might have affected DisplayLink support. I see errors for both releases in the interrogate output indicating that DisplayLink driver support for I2C is incomplete. Without having a DisplayLink device to test with it's hard to say what's going on.

However, I do have a hunch it has to do with the increased use of /sys to improve performance. This has proven problematic because of differences in driver implementations. The version of interrogate in branch 2.1.5-dev reports /sys attributes much more extensively. Can you build from that branch and run interrogate again? Also, please install packages i2c-tools and read-edid which are used by interrogate if they are installed.

[arthurrump]

Always fun when things do work against all expectations :smile:

Here's the output of interrogate on 2.1.5-dev (b3573c2 to be specific): https://gist.github.com/arthurrump/62659ae7dc2f9904bddf5ee9a7f786a0#file-ddcutil-2-1-5-dev

[arthurrump]

Did a little (well, quite large between 2.0.0 and 2.1.0) bisection as I now had a build setup going: looks like d1d0a24b57289557860dea7df3f66978c2c46678 still works and 154e00a3d2317d32a1796fcebb85b8d09dc6fbfe is the first where no displays are detected. The commits in between produce build failures.

# possible first bad commit: [154e00a3d2317d32a1796fcebb85b8d09dc6fbfe] clean up logic attached buses vs buses w connected displays
# possible first bad commit: [ed0081b3aa629fb0c95d72b8549405f96c527923] --f14 enables getting EDID from /sys instead of disables
# possible first bad commit: [f1bb7b495a1e20a71edbfd017b87045584727e2e] CMD_FLAG_F14 sets force_read_edid false
# possible first bad commit: [f9493cd7a0cdc7d81262aa2e4dd8ebbda87695cf] reflect rename DEFAULT_DDC_CHECK_ASYNC_MIN -> DEFAULT_DDC_CHECK_ASYNC_THRESHOLD
# possible first bad commit: [28b7b345a3180130dc46dfb760738f242796ddc7] set initial value of force_read_edid = true, misc cleanup
# possible first bad commit: [31e8c1096cf840ff617c6e41532068ae56fd9c5d] rename i2c_buses_to_bitset() -> buses_bitset_from_businfo_array()
# possible first bad commit: [2507787e992dee0d32e17827d718adeb585269b3] reflect name change i2c_buses -> all_i2c_buses
# possible first bad commit: [bb151eab84bcab904f26588f872794e6d02b80f7] misc cleanup
# possible first bad commit: [3eafcb82f2f9923b914f13c35de7b4b818bfc2c8] add i2c_detect_attached_buses_as_bitset(), delete i2c_get_all_buses()
# possible first bad commit: [f0b6224e3663baac6e18b14956162bd4e05f042c] rename --ddc-check-async-min -> --ddc-check-async-threshold
# possible first bad commit: [92e2249d8aeec44d9f3048563c69f1e4a983ae0a] make --i2c-bus-check-async-min hidden, corruption seen when parallel detection
# possible first bad commit: [c941da27d048550bb35a825b4fc4830c182d6c0b] rename symbolic constants, rearrange for clarity

[rockowitz]

Commit b3573c2 is irrelevant to your problem. It applies only to libddcutil, not command line ddcutil.

The relevant commit, which you located, is 28b7b345a. The solution is not trivial. The interrogate output for branch 2.1.5-dev clarified the problem. Prior to that commit, display detection was using /sys if possible to get the EDID instead of reading it from the I²C bus. The presence/absence of the sysfs edid attribute was used to indicate that a the display on the bus was disconnected or changed. Unfortunately, as noted in the log entry for the change, this use of /sys proved unreliable. Some drivers populate the attribute once and never change it.

The DisplayLink driver supports DDC on slave address x37, but not reading the EDID on slave address x50. The only way to get the EDID is from /sys. Display detection worked prior to 28b7b345a because ddcutil looked in sysfs before trying to read it directly over the I²C bus. But as noted, it turned out that ddcutil cannot rely on the accuracy of the value in /sys, so now always reads it directly.

The proper solution would be for the DisplayLink driver to provide the EDID on slave address x50, which should be trivial given the support for much more complex slave address x37.

In short, supporting DisplayLink displays along with "traditional" displays will require special purpose code. I'll keep this in mind when I work on the relevant sections of code, but a solution will not be immediate. I trust I'll be able to ask you to run tests from time to time.

[rockowitz]

I posted a detailed follow-up comment, but it seems to have been lost. In brief, branch 2.1.5-dev contains special code for reading the EDID of DisplayLink devices. Let me know if ddcutil now works for you.

I've added code in branch 2.1.5-dev to command interrogate to explore how DisplayLink uses sysfs. Please rerun interrogate and submit the output. Thank you.

[arthurrump]

On 325e1cf both of my screens are detected again and brightness control works. Awesome, thanks for the quick fix! :rocket:

Here's the interrogate output on that version: https://gist.githubusercontent.com/arthurrump/62659ae7dc2f9904bddf5ee9a7f786a0/raw/a29b8e748de44c973d02d4f5a51f3abde686a54d/ddcutil-2.1.5-dev-325e1cf