detect command reports same monitor as 2 different /dev/i2c devices

[rockowitz]

Sometimes a DisplayPort connected monitor is reported as 2 different /dev/i2c devices, e.g. /dev/i2c-3 and /dev/i2c-8. Sometimes only one of the /dev/i2c devices supports DDC communication and ddcutil can filter it out, at other times both /dev/i2c devices support DDC communication and the detect command reports them both.

This is clearly a video driver problem. If I can understand it better I will create a bug report for the relevant driver(s), and will likely be able to create a workaround until the bug is resolved.

Code has been added to the environment command to better analyse this situation. This code currently (12/18/2020) exists only in the development branch, 1.0.0-dev. If you encounter this situation, and can build from that branch, please run ddcutil environment --verbose as root and send the output as an attachment, gist, pastebin record or such. Please, do not include the output in your message body It's voluminous and makes the issue thread unreadable.

Thank you.

[evgeni]

here it the ddcutil environment --verbose output for my setup (see below): https://gist.github.com/evgeni/95355c7d0f288ccad99ba84ecd009c73

% sudo ddcutil detect               
Invalid display
   I2C bus:             /dev/i2c-4
   EDID synopsis:
      Mfg id:           BOE
      Model:            
      Serial number:    
      Manufacture year: 2017
      EDID version:     1.4
   DDC communication failed
   This is an eDP laptop display. Laptop displays do not support DDC/CI.

Invalid display
   I2C bus:             /dev/i2c-5
   EDID synopsis:
      Mfg id:           AOC
      Model:            U2790B
      Serial number:    
      Manufacture year: 2020
      EDID version:     1.4
   DDC communication failed

Display 1
   I2C bus:             /dev/i2c-7
   EDID synopsis:
      Mfg id:           AOC
      Model:            U2790B
      Serial number:    
      Manufacture year: 2020
      EDID version:     1.4
   VCP version:         2.2

[rockowitz]

@evgeni My apologies. I neglected to say that the additional code to probe /sys exists only in the 1.0.0-dev development branch. (My post of 12/16 has been updated to note this.) Are you able to build from that branch and rerun ddcutil environment --verbose? Thanks.

[evgeni]

I tried, but when I call it, I just get ddcutil requires module i2c_dev. and that's all

[rockowitz]

I just pushed recent changes to 1.0.0-dev. The check for i2c_dev should work properly now.

[evgeni]

nope, you still need #161 ;)

[evgeni]

output after the patch: ddcenv.txt

[rockowitz]

**ddcutil environment --verbose" in branch 1.0.0-dev has been updated yet again to dump out even more of /sys. Please run it when you can. Thank you.

[lentinj]

I'm also suffering this. I have 2 identical dell monitors daisy-chained via. a NUC NUC5i3RYB's display port, but there's 2 versions of the first monitor in the chain, one named "AUX C/port C", one named "DPMST". The monitor responds to commands from both instances.

Here's a dump after compiling 1.1.1-dev, I've only allowed my user access to the relevant monitor devices, thus the errors, but adding the rest doesn't seem to make much difference.

ddcutil-1.1.1-dev.envverbose.txt

[rockowitz]

Thank you for sending the report. I must admit I'm having difficulty making sense of the the behaviour. Can I ask you to run ddcutil --environment --very-verbose and also ddcutil detect --verbose and send the output. --very-vebose is an undocumented option that extensively probes /sys. Thanks

[lentinj]

Sure, sorry for the delay, attached. Since the previous log I've disconnected the daisy-chained monitor to simplify matters. It doesn't make a difference to the issue at hand, beyond the additional "DPMST" device.

• ddcutil-1.1.1-dev.detectverbose.txt
• ddcutil-1.1.1-dev.envveryverbose.txt

FWIW I also tried the same monitor / cable combination on a Thinkpad T460s and X230. The former sees the same, the latter only the AUX I2C connection (which I guess just tells you that the relatively ancient Intel chip inside doesn't support MST). I don't have any non-i915 hardware to try I'm afraid.

The obvious answer to my untrained eye would be to ignore the DPMST I2C bus if there's an AUX bus seemingly going to a monitor with the same model/serial number. Although both work equivalently in my case, by the sounds of it that's not guaranteed, and MST working at all is a relatively recent development. There's an i915.enable_dp_mst option I could toggle, but then I couldn't get at the daisy-chained monitor, which is only available via. MST.

[rockowitz]

Thanks for the updated reports. Just when I think I've got a clear handle on what's going on, a new variant of the problem surfaces.

The latest version of ddcutil environment --very-verbose* includes yet another /sys scan. I've tried to limit its reporting to attributes relevant to the duplicate display problem, which makes it easier to analyse. Its titled "Simplified /sys/bus/pci/devices scan". Note that the output of ddcutil detect --very-verbose is now part of environment --verbose and environment --very-verbose, so there's no need to invoke it separately. It would be helpful if you re-run ddcutil environment --very-verbose and submit the output.

I've posted a general description of the problem, titled "Same MST Display appears as 2 /dev/i2c devices" to the freedesktop.org drm/amd issues list, and cross-posted to the drm/intel issues list. I suggest you add yourself to the interested parties, upvote the problem, and add whatever detail you can to the post on the Intel list.

[rockowitz]

@evgeni @BenWShade @laur89 @siwonpatel and anyone affected by the MST double detection problem.

I want to draw your attention to the immediately prior post for this issue, I have submitted a problem report titled Same MST display appears as 2 different I2C devices to the freedesktop.org drm/amd issues list, and cross-posted to the drm/intel issues list. If you're affected by this problem, consider adding yourself to the interested parties for the gitlab issue, upvote the problem, and add whatever detail you can to either the AMD or Intel post.

[pawelsiwon]

@rockowitz I have missed your latests comment here, I was checking if there are any problems with double-detection of one monitor. Now I am using a company computer with USB-C to DisplayPort dongle and an Intel Graphics Card (so its not only related to my private setup with Nvidia's card), and one of the monitors is double listed under diffetent i2c buses. I will check attached bug reports on freedesktop.org and try to provide additional information there.

[rockowitz]

@siwonpawel If you're still seeing the problem, please build from branch 1.2.3-dev, which contains improved analysis of /sys/class/drm and /sys/bus/i2c, then execute command ddcutil environment --verbose and submit the output as an attachment.

Also, see this post on the freedesktop.org issues list. (It's not clear to me whether the changes in the TIP have made it into the kernel.) You may want to try building the TIP and see if that makes a difference.