Diagnosing HP 22cwa Invalid display and DDC communication failed

[yuki-tsubaki]

I am trying to use ddcutil to change the brightness of my monitor (HP 22cwa). The monitor lists "DDC/CI Support" in its OSD and it is turned on right now. Despite this when I use sudo ddcutil detect and other commands, things do not work.

I have looked on ddcutil.com and did not find this listed in the notes on specific monitors section or information on the recommended sites for checking specs (seems like it is very unpopular as there is very little information outside of HP's own product listings).

I am currently trying to determine weather these errors are caused by marginal/nonstandard/lack of implementation of DDC by the monitor, or something else like a hardware problem.

Here is the output of sudo ddcutil detect --verbose (for the overview; I omitted the laptop display's information):

Invalid display
   I2C bus:  /dev/i2c-6
      DRM connector:                         card1-HDMI-A-1
      /sys/class/drm/card1-HDMI-A-1/dpms     On
      /sys/class/drm/card1-HDMI-A-1/enabled  enabled
      /sys/class/drm/card1-HDMI-A-1/status   connected
      Driver:                                amdgpu
      I2C address 0x50 (EDID) responsive:    true 
      I2C address 0x37 (DDC)  responsive:    true 
      Is LVDS or EDP display:                false
      Is laptop display by EDID:             false
      Is laptop display:                     false
      /sys/bus/i2c/devices/i2c-6/name        AMDGPU DM i2c hw bus 1
      PCI device path:                       /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/i2c-6
   EDID synopsis:
      Mfg id:               HWP - Hewlett Packard
      Model:                HP 22cwa
      Product code:         12675  (0x3183)
      Serial number:        6CM7430V5C
      Binary serial number: 16843009 (0x01010101)
      Manufacture year:     2017,  Week: 43
      EDID version:         1.3
      Extra descriptor:        
      Video input definition:    0x80 - Digital Input
      Supported features:
         DPMS active-off
         Digital display type: RGB 4:4:4 + YCrCb 4:4:4
         Standard sRGB color space: False
      White x,y:        0.313, 0.329
      Red   x,y:        0.653, 0.336
      Green x,y:        0.324, 0.612
      Blue  x,y:        0.151, 0.065
      Extension blocks: 1
   EDID source: I2C
   EDID hex dump:
              +0          +4          +8          +c            0   4   8   c   
      +0000   00 ff ff ff ff ff ff 00 22 f0 83 31 01 01 01 01   ........"..1....
      +0010   2b 1b 01 03 80 30 1b 78 2a 43 f5 a7 56 53 9c 26   +....0.x*C..VS.&
      +0020   10 50 54 a1 08 00 d1 c0 81 c0 a9 c0 b3 00 95 00   .PT.............
      +0030   81 80 81 00 01 01 02 3a 80 18 71 38 2d 40 58 2c   .......:..q8-@X,
      +0040   45 00 dc 0c 11 00 00 1e 00 00 00 fd 00 32 3c 1e   E............2<.
      +0050   50 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 48   P...      .....H
      +0060   50 20 32 32 63 77 61 0a 20 20 20 20 00 00 00 ff   P 22cwa.    ....
      +0070   00 36 43 4d 37 34 33 30 56 35 43 0a 20 20 01 d0   .6CM7430V5C.  ..
   DDC communication failed. (getvcp of feature x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)])

(I didn't know if this was long enough that you want it in an attachment so sorry if that was the case).

Here is the full output of sudo ddcutil interrogate --verbose sudo-ddcutil-interrogate---verbose.txt

Something of note is that when using the --ddc flag the response bytes (if I am interpreting the meaning of the messages correctly) seem to be shifted forms of the expected values.

For example here is a portion from sudo ddcutil detect --ddc

DDC: Unexpected source address 0xbe, should be 0x6e
DDC: i2c_response_bytes: be 00 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80 be 6e 80

I looked this up in the issues and found #46 which seems to be similar, but I wouldn't know to what extent (I don't have a Windows computer or logic analyzer). I have tried it from another Linux computer (that one over a thunderbolt dock) and it fails as well (I can send that if you are interested).

I have also run other commands with and various --sleep-multiplier values (which I assume is the new name for the --sleep-strategy option mentioned; it did not fix anything). I can send those if you are interested.

Thanks for maintaining and doing so much to support users.

[rockowitz]

The combination of ryzen integrated video and your particular monitor is resulting in invalid DDC/CI reply packets. You are correct that that's what the output from --ddc is showing. The repeated DDCRC_DDC_DATA status codes on ddcutil detect also indicate the same thing. Beyond setting a high sleep multiplier the only ddcutil option that has a remote possibility of correcting this is --use-file-io which causes ddcutil to take an alternative path through driver i2c_dev.

Of course, connecting a different display to the laptop and trying the monitor on another computer might isolate the problem to the monitor.

[yuki-tsubaki]

I don't think I have another monitor that supports DDC, so might be a while before I can get around to testing that.

My other older computer uses Intel 620 integrated graphics and I did test it on there as well and still have a similar issue (I should note that that one is connecting using a Thunderbolt hub; not direct HDMI).

Here are those files:

sudo-ddcutil-detect---ddc.intel.txt sudo-ddcutil-detect---verbose.intel.txt .intel.txt) sudo-ddcutil-interrogate---verbose.intel.txt

Notably the byte shift seems to happen there too. I tested with various --sleep-multiplier values (2 4 10 15 20 99) and it still fails.

Using --use-file-io also fails similarly on both computers.

Also of note, I got "DDC: Quirk: response packet starts with double 0x6e" a few times (it is very inconsistent but saw it on the ryzen computer when while using the --use-file-io option.

[rockowitz]

Given that the data errors persist when you move the monitor to another computer strongly suggests the problem is in the monitor's DDC implementation.

The initial double 0x6e is one of the few situations where ddcutil can recover from invalid data.

As a practical matter, there's no point in trying a sleep multiplier greater than 4.

[yuki-tsubaki]

Ok, sounds good. Thanks for the help. Is there anything else that needs to be done--like adding this to the docs? (I don't know if it is important given this monitor seems to be practically forgotten by everyone except HP.) If not, I'll mark this issue as resolved.