Frequently Asked Questions

ddcutil can't communicate with a monitor when it's plugged into a docking station.

ddcutil does work when the monitor is plugged directly into the laptop. The problem affects DisplayPort, DVI, and HDMI connectors on the dock.

This is a problem with newer docking stations that implement DisplayPort Multi Stream Transport, and appears to be a bug in the DRI driver code.

For the gory details, see this thread on the Intel-gfx developers list.

I'm using Nvidia's proprietary driver. ddcutil doesn't seem to be be working.

Symptoms include "DDC communication failed" on ddcutil detect, and lots of "Maximum retries exceeded" errors on command ddcutil getvcp known.

You may need the Nvidia secret handshake. See Special Nvidia Driver Settings.

The capabilities command reports the MCCS (aka VCP) version, but elsewhere ddcutil says the version is unknown.

DDC/CI has two ways of reporting the the MCCS version:

  • As part of the capabilities string returned in response to a DDC Capabilities Request.
  • As the response to a VCP Feature Request for feature xDF (VCP Version).

Sometimes they disagree.

Command ddcutil capabilities reports the response to the DDC Capabilities Request. However, ddcutil regards this output as purely informational. It does not use the capabilities string when formulating commands and interpeting responses. This is for multiple reasons:

  • A DDC capabilities request requires multiple I2C exchanges, making it both slow and unreliable. Because of its complexity, it is particularly vulnerable to I2C errors. On monitors with paticularly poor I2C implementations it sometimes fails because the maximum number of I2C retries is exceeded.

  • There is no capabilities request defined in the programming interface for USB connected monitors. ddcutil simulates a capabilities response by looking at what USB HID reports exist for feature codes.

  • The response to the DDC capabilities API request may be incorrect. For example, the capabilities response from the HP LP2480zx monitor does not list VCP feature code x10 (brightness) as supported. However, feature code x10 is in fact supported. The only way to know for sure if a monitor implememts a VCP feature code is to try it.

ddcutil therefore relies on VCP feature code xDF to determine the VCP version. (For USB connected monitors, it queries HID usage x00800004.) It is possible that feature code xDF is unsupported, even though the capabilities response specifies a version.

The output of the capabilities command is incorrect.

For example, a Dell P2210 monitor has VGA, DVI, and DisplayPort inputs, but capabilities only reports:

 Feature: 60 (Input Source)
    Values (unparsed): 01 03
    Values (  parsed):
       01: VGA-1
       03: DVI-1 

The capabilities string reported by a monitor is often incorrect. While the ddcutil capabilities command parses and reports the string, this is solely informational.

The only way to know for sure if a monitor supports a VCP Feature Code is by testing using the getvcp and setvcp commands.

The following command will attempt to read all VCP codes that ddcutil understands, other than those that are write-only:

ddcutil getvcp known

To attempt to read all possible VCP codes, whether understood by ddcutil or not, except for those that are known to be write-only:

ddcutil getvcp scan

To see all the values defined for a non-continuous (NC) feature code, i.e. one with discrete values, use the vcpinfo command with the --verbose option. For example, to see all the values defined in the Monitor Control Command Specification for VCP feature x60 (Input Source):

# ddcutil vcpinfo 60 --verbose

VCP code 60: Input Source
   Selects active video source
   MCCS versions: 2.0, 2.1, 3.0, 2.2
   MCCS specification groups: Miscellaneous
   ddcutil feature subsets: 
   Attributes (v2.0): Read Write, Non-Continuous (simple)
   Attributes (v2.1): Read Write, Non-Continuous (simple)
   Attributes (v3.0): Read Write, Table (normal)
   Attributes (v2.2): Read Write, Non-Continuous (simple)
   Simple NC values:
      0x01: VGA-1
      0x02: VGA-2
      0x03: DVI-1
      0x04: DVI-2
      0x05: Composite video 1
      0x06: Composite video 2
      0x07: S-Video-1
      0x08: S-Video-2
      0x09: Tuner-1
      0x0a: Tuner-2
      0x0b: Tuner-3
      0x0c: Component video (YPrPb/YCrCb) 1
      0x0d: Component video (YPrPb/YCrCb) 2
      0x0e: Component video (YPrPb/YCrCb) 3
      0x0f: DisplayPort-1
      0x10: DisplayPort-2
      0x11: HDMI-1
      0x12: HDMI-2

In practice, any given monitor will implement only a few of the NC values, and some monitors will implement undocumented values. The only way to know for sure is by testing.

ddcutil detect --verbose reports that both I2C address x50 (EDID) and x37 (DDC) are responsive, but DDC communication fails.

There can be any number of reasons for this situation.

The same DisplayPort connected monitor appears twice in the output of ddcutil detect.

Sometimes the same DisplayPort connected monitor is detected at 2 different I2C bus numbers. ddcutil detect reads the EDID at on both buses, but DDC communication succeeds on only 1 bus. The other bus is regarded as an invalid display. The invalid bus appears to be related to the DisplayPort multistream facility. You can ignore the invalid entry.

The detect command reports different EDIDs depending on how the monitor is connected to the video card.

Strange as it may seem at first, a monitor can have more than one EDID. The EDID for a VGA connection will have a different video input definition (byte x14) than that for a digital connection. The VGA version of the EDID will have timing information.

The detect command reports that I2C bus address x30 (EDID block number) is inactive.

EDID version 1.4 allows for addtional 128 byte EDID blocks. I2C bus address x30 specifies which block to read. These blocks generally contain extended timing information. ddcutil is interested only in the contents of the first EDID block. The check of bus address x30 is purely informational.

Recent laptops use Embedded Display Port (eDP) panels which have an I2C interface. Why doesn't ddcutil work?

The I2C connection on eDP panels implements slave address x50, which allows programs to read the EDID in the expected way. However, it does not implement slave address x37, i.e. it does not support DDC/CI.

If eDP panels did implement DDC/CI, ddcutil would support it. For each I2C bus that could possibly be associated with a monitor, as part of display detection ddcutil attempts to read the EDID at slave address x50. If successful, it then attempts to communicate on slave address x37. If that fails, and display detection is occurring in the context of ddcutil detect --verbose, ddcutil then looks for a possible reason, and checks to see if the display is a laptop. If so, it then reports that laptops to not support DDC/CI.

ddcutil does not work on a Raspberry Pi 4

The HDMI related chip has been changed on the Raspberry Pi 4, and drivers have not yet been revised to enable userspace access to /dev/i2c-2. For details, see page Raspberry Pi.

configure complains that a required package does not exist, but it is installed on my system.

When building ddcutil, error messages from pkg-config (which is called by configure) can be misleading. If configure complains that a package is not found but it seems to be installed, it's likely that what's missing is the associated development package (with a suffix like "-dev").