Hexdump prefix and invalid displays on LG 34WK95U-W.AEU

[jcassee]

When I use ddcutil detect the output is prefixed with a hexdump. I am using a tiled display (LG 34WK95U-W.AEU), and only one "display" is recognized as usable. (Which is fine.) However, because of the extra output, many tools that use ddcutil fail to parse the output.

Example:

 ddcutil detect
                    +0          +4          +8          +c            0   4   8   c
            +0000   00 ff ff ff ff ff ff 00 1e 6d 21 77 99 18 07 00   .........m!w....
            +0010   06 1f 01 04 b5 50 21 78 f8 09 c1 ae 50 44 af 26   .....P!x....PD.&
            +0020   0e 50 54 21 08 00 01 01 01 01 01 01 01 01 01 01   .PT!............
            +0030   01 01 01 01 01 01 00 00 00 00 00 00 00 00 00 00   ................
            +0040   00 00 00 00 00 00 00 00 00 00 00 fd 00 30 3d 1e   .............0=.
            +0050   87 4c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c   .L..      .....L
            +0060   47 20 48 44 52 20 35 4b 0a 20 20 20 00 00 00 ff   G HDR 5K.   ....
            +0070   00 31 30 36 4e 54 57 47 44 50 30 34 39 0a 01 d1   .106NTWGDP049...
            +0080   70 12 79 03 00 01 00 0c 40 1f e4 0c 00 14 70 08   p.y.....@.....p.
            +0090   90 78 89 99 12 00 16 80 10 10 00 ff 09 6f 08 00   .x...........o..
            +00a0   00 00 00 00 47 53 4d 21 77 01 01 01 01 03 01 14   ....GSM!w.......
            +00b0   99 8d 00 08 ff 09 9f 00 2f 80 1f 00 6f 08 3d 00   ......../...o.=.
            +00c0   02 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            +00d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            +00e0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            +00f0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 90   ................
Invalid display
   I2C bus:  /dev/i2c-11
   DRM connector:           card0-eDP-1
[...]

This is the full ddcutil introspection:
ddcutil-interrogate.log

[rockowitz]

It looks like a bit of debug output is turned on. Locating exactly where will likely be a pain to diagnose remotely.
As a first step, please execute ddcutil detect --trace i2c and submit the output. Thank you.

[jcassee]

This is the output of ddcutil detect --trace i2c:

dccutil-detect-trace.log

[rockowitz]

The output of the trace log does not appear to be from the same physical configuration as your original report. The detect command has no output for the LG 5K monitor reported as "Display 1". Please run ddcutil detect --trace i2c with the LG monitor connected in the same way.

[jcassee]

Argh, of course, sorry about that. This is one with the monitor connected:

dccutil-detect-trace.log

[rockowitz]

The output isn't happening within a low level I2C function. Let;s try ddcutil detect --trace ddc --trace ddcio.

[rockowitz]

I believe I've found the locus of the errant hex dump. The bug is in the infrequently executed code that checks for phantom displays. That code was apparently triggered because your tiled display causes the same EDID to appear on two different /dev/i2c buses.

After executing ddcutil detect --trace ddc --trace ddcio as previously requested, try building from branch 2.1.5-dev and see if the problem persists.

[jcassee]

The output of ddcutil detect --trace ddc --trace ddcio:
dccutil-detect-trace.log

I tried to compile from source on my Arch Linux system, but I get this error, even though /usr/include/libdrm/drm_mode.h exists and LIBDRM_CFLAGS = -I/usr/include/libdrm is in all the Makefiles.

make  all-recursive
make[1]: Map '/home/joost/Ontwikkeling/Utilities/ddcutil' wordt binnengegaan
Making all in src
make[2]: Map '/home/joost/Ontwikkeling/Utilities/ddcutil/src' wordt binnengegaan
Making all in util
make[3]: Map '/home/joost/Ontwikkeling/Utilities/ddcutil/src/util' wordt binnengegaan
  CC       drm_common.lo
drm_common.c:22:10: fatal error: drm/drm_mode.h: No such file or directory
   22 | #include <drm/drm_mode.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [Makefile:552: drm_common.lo] Fout 1
make[3]: Map '/home/joost/Ontwikkeling/Utilities/ddcutil/src/util' wordt verlaten
make[2]: *** [Makefile:816: all-recursive] Fout 1
make[2]: Map '/home/joost/Ontwikkeling/Utilities/ddcutil/src' wordt verlaten
make[1]: *** [Makefile:494: all-recursive] Fout 1
make[1]: Map '/home/joost/Ontwikkeling/Utilities/ddcutil' wordt verlaten
make: *** [Makefile:424: all] Fout 2

(It's been a while since I compiled C sources, sorry...)

[rockowitz]

I have cleaned up the drm.h includes in branch 2.1.5-dev. Let me know if it builds properly and the problem is solved. Thanks so much for your help.

[jcassee]

The build succeeds now. 👍

This is the output of ddcutil detect now:

$ ddcutil detect
   Failure retrieving DRM resources, errno=95=Operation not supported
Invalid display
   I2C bus:  /dev/i2c-11
   DRM connector:           card1-eDP-1
   EDID synopsis:
      Mfg id:               SHP - Sharp Corporation
      Model:
      Product code:         5399  (0x1517)
      Serial number:
      Binary serial number: 0 (0x00000000)
      Manufacture year:     2021,  Week: 10
   This is a laptop display.  Laptop displays do not support DDC/CI

Display 1
   I2C bus:  /dev/i2c-14
   DRM connector:           card1-DP-3
   EDID synopsis:
      Mfg id:               GSM - Goldstar Company Ltd (LG)
      Model:                LG HDR 5K
      Product code:         30497  (0x7721)
      Serial number:        106NTWGDP049
      Binary serial number: 465049 (0x00071899)
      Manufacture year:     2021,  Week: 6
   VCP version:         2.1

Invalid display
   I2C bus:  /dev/i2c-15
   DRM connector:           card1-DP-4
   EDID synopsis:
      Mfg id:               GSM - Goldstar Company Ltd (LG)
      Model:                LG HDR 5K
      Product code:         30497  (0x7721)
      Serial number:        106NTWGDP049
      Binary serial number: 465049 (0x00071899)
      Manufacture year:     2021,  Week: 6
   DDC communication failed. (getvcp of feature x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_NULL_RESPONSE(3), DDCRC_DDC_DATA, DDCRC_NULL_RESPONSE(6)])

Are those first and last lines expected?

(The utility I'm trying to use, the Gnome Brightness control extension, gives the last line back as an error message: ddcutil[37653]: busno=15, sleep-multiplier = 2.00. Testing for supported feature 0x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_NULL_RESPONSE(10)].)

[rockowitz]

The "Failure retrieving DRM resources" message reports an unexpected error in new code under development, intended to improve performance. You can ignore it.

The text in parentheses after "DDC communication failed." is an informational message intended to provide detail as to how communication failed. In your case, the monitor reports each "logical" display as being on a separate I2C bus. On the second logical display the firmware in the monitor reports the EDID, but does not implement DDC/CI. Ideally, the display on /dev/i2c-15 would be reported as a "Phantom display" instead of the more generic "Invalid display", but the code for categorizing a display as "phantom" is conservative.

Finally, it's unfortunate if the Gnome Brightness extension is confused by changes to the output of the detect command, but that is the nature of screen-scraping. Generally speaking, ddcutil output is intended for human consumption, not machine consumption, There is no guarantee that it will be unchanged from one release to the next. Emitting output in a structured form such as JSON or YAML, is an outstanding feature request.

[rockowitz]

The detail on detect as to why DDC communication failed has turned out to be as much a source of confusion as an explanation. With the latest update to 2.1.5-dev, the detail is only shown for --verbose output. It is reported on a separate line.

[jcassee]

I agree that the Gnome Brightness extension (and other tools) should not try to parse the output of ddcutil. I guess it speaks to the success of the tool, and the absence of better tools for automation. I did find ddcutil-service, seems like a nice (but new) project.

In any case, thank you for removing the explicit error message and keeping it to the neutral "DDC communication failed".

[rockowitz]

I think that ddcutil-service will eventually become the way that most applications, or at least simple applications that now rely on screen-scraping, use ddcutil. Having a second real application, after ddcui, that uses libddcutil has driven the development of the shared library for the past few months.