DDC failed with ASUS B227s

[ghost]

I have 2 slightly different ACER monitors - One is working a bit but not fully and the other is getting DDC communication failed from my RHEL 8 box - ddcutil manually compiled. The system is a Thinkpad on a docking station. The monitors themselves are connected to 2 PCs (the Thinkpad and another desktop) on different inputs. Only running ddcutil from the Thinkpad RHEL 8/ The laptop Thinkpad is screen is as expected but one ACER B277U monitor DDC is reports Null response and the other B277 (no U) DDC communitcaiton failed. Checked both OSDs and DCC/CI is on for both. Enclosed ddcutil environment --verbose output in env_output.txt Any suggestions? env_output.txt

[ghost]

I am guessing this is to do with the combination of the docking station and DVI. The DDC comms failed is for the DVI connection via the docking station. The other (B277U) is connected directly from the laptop via HDMI.

[rockowitz]

There are problems in the DRM drivers (i915, amdgpu, etc.). A lot of effort has gone into the upcoming release to detect and to some extent work around these problems. (See the preliminary notes for the upcoming release.) Try building from the 1.1.0-rc1 branch that was released this morning. Whether or not the problems persist, please submit the output from "environment --very-verbose" .

[ghost]

Thanks - I made (autogen.sh) and installed 1.1.0-rc1 (well I think I did it right), but get root:ddcutil-1.1.0-rc1# ddcutil ddcutil: string_util.c:577: ntsa_length: Assertion `string_array' failed. Aborted (core dumped) Not had time to dig into why

[rockowitz]

You hit a bug in the recently added configuration file code. As a work-around, create a dummy configuration file: $ touch $HOME/.config/ddcutil/ddcutilrc

[ghost]

Thanks that ran - Still says 1.0.2 as version?? but is a new exe built today from the right dir and has recent timestamp ddcutil environment --very-verbose is in dcc110rc1.txt (dcc is typo!) Similar results to initial issues. dcc110rc1.txt

[rockowitz]

There are 2 separate problems going on.

The DDC "Null Response" is a well formed DDC response from the monitor. It's a bit of a catch-all, but basically it's the monitor saying that it can't handle the request for some reason. Some monitors misuse this response to indicate an unsupported feature, instead of setting the unsupported feature bit in a normal getvcp reply. What feature(s) did this fail for? The environment command tests indicate that getvcp of feature x10 (brightness) succeeds.

The failure of DDC communication on /dev/i2c-6, which appears to be the monitor on the docking station, is a driver issue. The docking station connectors are MST devices linked to one of the connectors on the laptop. Normally, the docking station connectors are named "MST". Sometimes the EDID of a docking station connected display is reported for the /dev/i2c device of the connector on the laptop that the displays on the docking station are linked to. Slave address x50 (EDID) works, but slave address x37 (DDC) does not. I refer to these as "phantom" displays. That is what you're seeing on /dev/i2c-6. This is readily confirmed by looking at the output of i2cdetect, which indicates slave address x50 is responsive, but not slave address x37.

I believe /dev/i2c-7 is actually the I2C device for the connector on the docking station. Its name is "MST", and i2cdetect indicates that both slave addresses x50 and x37 are responsive. The algorithm used by "ddcutil detect" to read the EDID from /dev/i2c-7 fails to read the EDID, so detect does not report the monitor. The extended diagnostics of the environment command test reading the EDID in several different ways, some of which do succeed. This is characteristic of MST devices. However, what's unusual in this case is that DDC communication also fails for this device.

What to try next?

Option "--edid-read-size 128" may allow the EDID on /dev/i2c-7 to be read.

Before doing the following, please build from branch 1.1.0-dev. I've added changes to improve tracing.

Run the command "ddcutil detect --very-verbose" and submit the output. If option "--edid-read-size 128" makes a difference, send output both with and without the option.

Next try issuing the command "ddcutil --bus 6 getvcp 10 --trcfunc ddc_i2c_write_read_raw --very-verbose". And a similar command for "--bus 7". If you are comfortable doing so, enable kernel tracing for these commands. A good description of how to do this is Tracing I2C Events.

Finally, it would be helpful to see the output of "ddcutil probe" for the monitor that's returning the Null Response. No need to make this verbose.

Regards, Sanford

[ghost]

OK enclosed a bunch of outputs from the commands hopefully as requested. The edid-read did not seem to do anything but have enclosed output anyway (but looks same to me) Did the kernel trace but did not make any noticeable difference to output either (again enclosed anyway) Hopeful file names make sense to marry up with requests. All on 1.1.0-dev Thanks ddcutil100bus6.txt ddcutil100bus6ktraceon.txt ddcutil100bus7.txt ddcutil100bus7ktraceon.txt ddcutil100detectedidveryverbose.txt ddcutil100detectveryverbose.txt ddcutil100probe.txt

[ghost]

Also tried again with 1.1.0-rc2 (the version number is correct now :) ) Display 1 direct HDMI (not via dock) seems to work for me now ddcutil detect & ddcutil capabilities --display 1 as well as some commands I have tried e.g ddcutil --display 1 getvcp 60 VCP code 0x60 (Input Source ): HDMI-2 (sl=0x12) gives a reasonable result with rc2 Think the issues are now just with the docking display (/dev/i2c-6) DDC communitcation failed.

[rockowitz]

Ben,

I should have caught this before, but looking at the environment output again I see that you're running kernel 4.18. Support for DDC on monitors connected to docking stations was not implemented until kernel 5.10.

Sanford

[ghost]

Ah I missed that as well. Unfortunately I can't fix/upgrade that till "allowed" as stuck on official RHEL 8 path, so will have to give up for the moment till RHEL get up to 5.10 which will be a while. Pity. Thanks for you help