Hexdump prefix and invalid displays on LG 34WK95U-W.AEU about ddcutil HOT 13 OPEN

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.

from ddcutil.

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

dccutil-detect-trace.log

from ddcutil.

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.

from ddcutil.

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

dccutil-detect-trace.log

from ddcutil.

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

from ddcutil.

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.

from ddcutil.

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...)

from ddcutil.

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.

from ddcutil.

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)].)

from ddcutil.

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.

from ddcutil.

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.

from ddcutil.

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".

from ddcutil.

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.

from ddcutil.