rockowitz
commented
3 years ago When you write "although ddcutil detectds the USB-C port it can't read the features/capabilities of the monitor", here's what I think you're describing:
The ddcutil command, and indirectly ddcui, scans each plausible /dev/i2c device to see if it is associated with a monitor. (Can the EDID be read? Is it responsive to to DDC commands? However, the USB-C value for feature x60 is unknown. It its not defined in the MCCS spec, and in fact different manufacturers use difference values. In the latest version of ddcui (not yet at github), if feature x60 initially reports an unexpected value for a non-continuous feature (e.g. x60), the combo box will continue to show that value as an option even after the value has changed. That avoid some unexpected behavior (the value was there, then it wasn't), but isn't a general solution. The proper solution is to use a user supplied feature definition. (See User Defined Features.
The second issue is discovering how Dell Display Manager controls the PBP facility. (Parenthetically, I regard enTech's softMCCS as the gold standard in general purpose DDC/CI utilities. They have a deep understanding of DDC/CI. If there were a Linux version, ddcutil/ddcui would not exist.) There are 3 possibilities:
1) DDM is using some combination of manufacturer reserved features (xE0..xFF), special logic for feature x60, and/or some otherwise undefined features to control PBP.
2) DDM is using the I2C bus in some way, but not using the DDC/CI protocol.
3) DDM is using USB to control PBP. Conceivable, but highly unlikely. The monitor manual gives no indication that USB is required. This is easily ruled out by using DDM to alter the PBP settings without any USB connections to the monitor.
Assuming it's (1), you could try observing the VCP feature values after the monitor's configuration has been changed by DDM or manually, and see what happens if you change the values of features in the manufacturer reserved range. This has been tried for at least one monitor (see issue #163) but reverse engineering the protocol has proven elusive.
The real solution is to sniff the I2C protocol on the cable connecting the monitor to a computer and see what requests DDM is issuing and what responses the monitor is sending. As a practical matter, this needs to be a HDMI or DVI connection. DisplayPort "multiplexes" the I2C signal over it's AUX channel, and Type-C carries a version of DisplayPort, so the I2C signal cannot easily be watched in these cases. I recently came across an inexpensive piece of open-source hardware that can sniff the I2C signal, called I2CDriver. I also came across this DDC/DVI breakout cable on closeout, which saved me an afternoon of soldering. I've tested it, and can indeed see the DDC/CI protocol in the captured bits and bytes. If you were to use this to capture the DDC/CI traffic, or have some other way to capture the traffic, I would be happy to help decipher the protocol and (assuming it's case(1) or a close variant in case(2), modify ddcutil to support it.
freestylo73
AachoLoya
microfortnight
Hi. First of all, a big thank you Sanford for your work with ddcutil, lifesaver on my particular setup.
What brings me here are two situations: one is that although ddcutil detects the USB-C port it can't read the features/capabilities of the monitor. Not a problem because connecting one of the two laptops it's enough to retrieve the binary code for the usb-c input.
The other situation is related with the kvm on board. Dell provides the Dell Display Manager (outsourced from entechtaiwan.com), and besides controlling/displaying the features/capabilities like ddcutil, it also does what I think (fingers crossed) are extended functions also provided by the monitor that I really hope can be controlled by ddcutil, at least the change of the mouse and keyboard (usb) between the laptops while in PBP mode. The full controll of the capabilities/features would be nice but I would be happy with the usb part of the kvm working. Do you think my reasoning it's correct or the control of the kvm is made separately? Thank you.
capabilities.txt