DDC get issues with CLI, 2 monitors and 2 computers

[mklein9]

Have been using BetterDisplay very happily for a few months. Just got 2 new identical monitors that BD is able to control well over DDC through the GUI app. One computer is a PC and it is using the Thunderbolt upstream inputs of both monitors. The other computer is an M1 Mac mini which must use the remaining non-TB inputs so I've picked HDMI. However, the Mac has one native HDMI output and the other display must be driven through a TB-to-HDMI adapter.

I have been able to set up having a single hotkey swap the inputs of both monitors using BD CLI, some shell scripting, and MacOS Automator, but along the way I found that there are quite a few parameters that fail the get command (return Failed.) on the monitor that has the TB-to-HDMI adapter in the path. In particular, reading the current state of the input selection fails: ./BetterDisplay get --originalName="DELL U2725QE 1" --ddc --vcp=0x60 (this is monitor 1 which has the get issue).

Throwing caution to the wind I decided to try just sending the set commands to switch the inputs, and they work on both monitors. Is there a reason why on one monitor the get commands fail while the set command works? Does the adapter block or corrupt the response?

Also BTW on the monitor where get works, ./BetterDisplay get --originalName="DELL U2725QE 2" --ddc --vcp=0x60 returns 4369, which happens to be 0x1111 and 0x11 is the correct HDMI1 code. Seems that BD CLI is printing the returned value twice, or printing two parameters' values that happen to be the same? In any case, writing a single value e.g. --vcp=0x60 --value=25 works to switch the input to Thunderbolt.

[waydabber]

Hi there - it could be the dock (as DDC communication from TB/DP to HDMI requires complex processing and translation and something might not work out - many HDMI docks or adaptors don't support DDC altogether) or the display does not return things properly via HDMI while it does via USB-C.

Regarding the funny return value, DDC read returns two bytes for the current value (the value range is 0-65535). It is probably a display firmware issue that simply repeats the current setting both in the high and low byte (instead of setting the high byte to 0). (Note: just to be sure, I quickly checked the code as well, it takes the proper bytes from the reply :)).