running environment cmd drops a display from detection

[laur89]

Hi again,

Issue

upon executing ddcutil environment --very-verbose, detect no longer shows the single valid display that's connected. Only way to get it detected again is to physically reconnect the monitor.

Repro (seems to reproduce consistently):

$ ddcutil --brief detect
ddcutil --brief detect
Invalid display
   I2C bus:          /dev/i2c-4
   DRM connector:    card0-eDP-1
   drm_connector_id: 100
   Monitor:          LEN::

Invalid display
   I2C bus:          /dev/i2c-8
   drm_connector_id: 0
   Monitor:          AUO::

Display 1                        <--  this is the display I'm talking about
   I2C bus:          /dev/i2c-11
   DRM connector:    card0-DP-6
   drm_connector_id: 0
   Monitor:          AUS:PA278QV:L8LMQS127231

2. run ddcutil detect --very-verbose --f2 (output in gist)
3. run ddcutil environment --very-verbose (output in gist)
   • this is the command that causes Display 1 to be lost.
4. run ddcutil detect --very-verbose --f2 (output in gist)

$ ddcutil --brief detect
Invalid display
   I2C bus:          /dev/i2c-4
   DRM connector:    card0-eDP-1
   drm_connector_id: 100
   Monitor:          LEN::

Invalid display
   I2C bus:          /dev/i2c-8
   drm_connector_id: 0
   Monitor:          AUO::

Note Display 1 is now droped.

---

ThinkPad p14s docked to 40AJ docking station. Running debian testing, ddcutil 2.2.1 installed from debian repos.

[rockowitz]

Do you encounter the problem without option --very-verbose?

[rockowitz]

Disregard the question about --very-verbose. Irrelevant. Do you encounter the problem if the monitor is plugged directly into the laptop when the docking station is/is not also connected?

[laur89]

Reproduces only with display connected directly to ~~laptop~~ dock. Tested with HDMI as that's the only port on laptop itself.

Also noticed it's roughly 3x as fast compared to dock connection:

$ hyperfine 'ddcutil setvcp --skip-ddc-checks 10 20 --bus 5'
Benchmark 1: ddcutil setvcp --skip-ddc-checks 10 20 --bus 5
  Time (mean ± σ):      68.2 ms ±   2.7 ms    [User: 4.5 ms, System: 13.7 ms]
  Range (min … max):    61.1 ms …  70.9 ms    43 runs
 
$ hyperfine 'ddcutil setvcp 10 20 --bus 5'
Benchmark 1: ddcutil setvcp 10 20 --bus 5
  Time (mean ± σ):     124.5 ms ±  10.0 ms    [User: 5.6 ms, System: 50.0 ms]
  Range (min … max):   105.5 ms … 133.8 ms    27 runs

Another thing of note was that when connected via HDMI (as opposed to DP) but via docking station, then ddci operations were also quicker, albeit more marginally so.

[laur89]

Sorry I had a brainfart earlier - meant to say it works correctly when hooked to laptop directly.

[rockowitz]

Pretty clearly a driver issue. The ddcutil environment --very-verbose output shows the same monitor on multiple /dev/i2c buses, which is often the case where MST is involved. See, for example, bug report Same MST display appears as 2 /dev/i2c devices.

Note that communication between the laptop an the dock is implemented using DisplayPort. It's the dock that converts the output to HDMI form for the HDMI connector. So I don't read much into the marginal difference between the DP and HDMI connectors on the dock.

The HDMI port is not the only video port on the laptop. Per the PSREF, DP output is also available on a USB C connector using a USB C <-> DP dongle.

[laur89]

The HDMI port is not the only video port on the laptop

True, but don't have a cable for that.

But yes, sounds like similar issue I reported handful of years ago. Docking stations be docking. If keeping this issue open is not beneficial, please close it.