ASUS PA278CV monitor shown as invalid monitor

[dyfrgi]

I have three monitors on my laptop: the built-in one, and two external ones connected via a Lenovo ThunderBolt 4 Dock (40B0). One of these is connected via DisplayPort and works fine with ddcutil. The other is connected via HDMI and does not work, instead being shown as being an invalid display. The i2c topology here seems to be pretty weird. /dev/i2c-16 is usable for getting an EDID from 0x50, but 0x37 is non-responsive. But then /dev/i2c-21 looks like a monitor - get-edid works on it, and i2cdetect shows the same bus addresses as being present.

I ran ddcutil interrogate --verbose on both 1.4.1, as included with my OS (Debian 12.4 bookworm), and on 2.1.0, as built from source (./autogen.sh; ./configure; make; sudo src/ddcutil interrogate --verbose). I ran the 2.1.0 version twice since the log mentioned that it was looking for possibly interfering programs, and I also had the ddccontrol daemon running at that time.

It's possible that this is an amdgpu driver bug. I did notice one weird thing about the "DisplayPort only attributes" reported for that monitor, notably that it has a ddc path that points to bus 9:

ddc path:                /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/i2c-9

But bus 9 has nothing on it. I'd appreciate some help in figuring out how to get this monitor working with ddcutil, or even just with a bit of code hacked together to write to VCP 60 so that I can change monitor inputs.

Tests I have not yet done but can do next time I'm working on this problem (it has been a couple hours so I need to get some actual work done):

• Connect the monitor to the laptop's built-in HDMI port, rather than via a hub
• Connect the monitor via DisplayPort via the hub
• Connect the monitor via DisplayPort to the laptop's built-in DisplayPort port
• Remove the other external monitor
• Try some DDC tools in Windows

If you think one of these is going to be more informative or fruitful, please let me know.

ddcutil-1.4.1-interrogate.log
ddcutil-2.1.0-interrogate.log

[rockowitz]

I'm afraid you're hosed. Driver MST I²C support is problematic. In some configurations it works with no issues, in some configurations there are "phantom" displays that ddcutil can filter out, and in some cases there's nothing that can be done. I've looked through your interrogate output, and there simply is no /dev/i2c device on which your AUS display communicates on slave address x37 (DDC). As background, here are some relevant driver bug reports.

[dyfrgi]

Aha, thanks for the information! I had looked at the drm gitlab for relevant issues but hadn't found them. I'll do some experimentating with how it's wired in the hope that one of the other ways works better. I also noticed that it's currently connected in USB mode, not Thunderbolt, which might make the topology differ. Unfortunately the Windows exploration I had planned would not use this hub so it probably won't be useful.

Would it also be helpful for me to open a new bug on the amdgpu side? From some other bug chatter over there AMD was doing a rework of their i2c code a few months ago, this might be a good time to get attention on MST i2c issues. Maybe there's some other information I should collect to include with that from debugfs, sysfs, etc.

Thanks for all your great work on this project!

[rockowitz]

Yes, this warrants a bug report vs. amdgpu. The interrogate command pretty much has all the information needed, but the relevant parts need to extracted and collated for a coherent bug report. After the point release goes out I can help you with that.

Since both your monitors have both DP and HDMI connectors, and IIRC one has a Type-C connector as well, and the dock has all three types of connectors, you might try different combinations to see if any work.