Hello, I’m having trouble using ddcutil to change the brightness via HDMI. It seems the video driver isn’t allowing me to access and control the corresponding I2C port. Thank you for your help.
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I’d be glad to help with your ddcutil HDMI brightness control issue! To provide the most accurate guidance, could you let me know which hardware and OS version you’re using?
Please run the tdx-info command to get your system information and share:
- Which SoM (System-on-Module) you’re using
- Which carrier board you have
- Your OS version (Torizon OS, BSP version, etc.)
You can find more details about the tdx-info command here: Getting Device Information with Tdx-Info | Toradex Developer Center
The I2C configuration and HDMI DDC (Display Data Channel) implementation varies significantly between different Toradex modules and OS versions, so knowing your specific setup will help me provide the correct solution for your ddcutil access issue.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Hello Marcelo,
Thanks for your message.
To help understand why ddcutil can’t access the HDMI DDC/I²C bus, could you share a bit more information about your setup?
Please run the following command and share the full output:
tdx-info
This will show details about the SoM, carrier board, and OS/Torizon/BSP version.
Which ddcutil command are you running exactly?
Please also include the full output or error message you get.
It would also help to check what I²C buses are visible and whether the HDMI driver is exposing the DDC bus. Please share the output of:
i2cdetect -l
dmesg | grep -i -e drm -e hdmi -e i2c
If the output is very long, you can trim it and keep only the lines related to HDMI or I²C.
Are you running ddcutil directly on the OS, or inside a container?
Hi Diego, thanks for your reply. I have the same monitor with both possible video outputs on the Verdin board. On the secondary board, the DDcutil works perfectly, but not on the onboard output. Looking at the clock and data signals from both outputs, I see that the clock frequency is different. The onboard output is approximately 100kHz, and the output that works is 9kHz. My conclusion is that the video driver is preventing me from accessing and controlling the I2C5, either for data or to make configuration changes, either with a shortcut or through DeviceTree by adding an overlay. My conclusion is that the video driver has captured the use of the I2C5 and DDcutils externally, but cannot read the data and responds by saying that the monitor is not compatible with DDC. When performing a memory dump, address 0x37 is not read, causing… This is the problem. Is there a way to control brightness and contrast using the video driver itself? I hope I’ve been clear. I’ve been dealing with this problem for a couple of days and it seems to be getting out of hand. Thanks.
Hi Marcelo,
Thanks for the detailed explanation, it helps a lot.
From what you described, it really sounds like the HDMI driver is taking exclusive control of the DDC/I²C bus on the on‑board HDMI output, while on the secondary output ddcutil can talk directly to the DDC channel. To move forward, I need to understand precisely how the two setups differ and how the I²C buses are exposed in each case.
First, could you clarify the difference between the two boards/outputs? Which carrier board are you using for the on‑board HDMI output where ddcutil fails, and which carrier board or adapter are you using for the secondary HDMI output where ddcutil works? Also, are both setups using the same Verdin iMX8M Plus SoM and exactly the same OS/Torizon/BSP image?
On the system where you are testing the on‑board HDMI output, please run the following command and share the full output:
ls -l /dev/verdin-i2c*
After that, please run:
i2cdetect -l
The idea is to compare the /dev/verdin-i2c* nodes with the list from i2cdetect -l and see how each Verdin I²C bus maps to /dev/i2c-*. This will let us check whether the DDC bus used by the on‑board HDMI is actually exposed as a regular I²C device node, or if it is only used internally by the HDMI driver.
If possible, it would be very helpful if you could provide these two command outputs for both situations: the configuration where ddcutil works (secondary output) and where it does not (on‑board HDMI). Please just indicate clearly which output corresponds to which setup.
Once we have this information, we can confirm whether your conclusion about I2C5/DDC being “captured” by the driver matches the actual mapping, and then discuss if brightness and contrast control is realistically possible via ddcutil on this output or if we need to rely on interfaces provided by the video driver itself.
Please share those outputs when you can, and we’ll continue from there.
Diego, here’s the summary of the commands you requested.
Om Board HDMI (Primary output):
seaman@seaman:~/seaman$ ls -l /dev/i2c-*
crw-rw----+ 1 root i2c 89, 0 Mar 4 16:43 /dev/i2c-0
crw-rw----+ 1 root i2c 89, 1 Mar 4 16:43 /dev/i2c-1
crw-rw----+ 1 root i2c 89, 2 Mar 4 16:43 /dev/i2c-2
crw-rw----+ 1 root i2c 89, 3 Mar 4 16:43 /dev/i2c-3
crw-rw----+ 1 root i2c 89, 6 Mar 4 16:43 /dev/i2c-6
seaman@seaman:~/seaman$ i2cdetect -l
i2c-0 i2c 30a20000.i2c I2C adapter
i2c-1 i2c 30a30000.i2c I2C adapter
i2c-2 i2c 30a40000.i2c I2C adapter
i2c-3 i2c 30a50000.i2c I2C adapter
i2c-6 i2c DesignWare HDMI I2C adapter
seaman@seaman:~/seaman$ sudo ddcutil detect
[sudo] password for seaman:
Invalid display
I2C bus: /dev/i2c-6
DRM connector: card0-HDMI-A-2
EDID synopsis:
Mfg id: RTK - UNK
Model:
Product code: 0 (0x0000)
Serial number: RTD
Binary serial number: 16843009 (0x01010101)
Manufacture year: 2021, Week: 1
This monitor does not support DDC/CI. (I2C slave address x37 is unresponsive.)
Board HDMI (secondary output):
seaman@seaman:~/seaman$ sudo ddcutil detect
Display 1
I2C bus: /dev/i2c-1
DRM connector: card0-HDMI-A-1
EDID synopsis:
Mfg id: RTK - UNK
Model:
Product code: 0 (0x0000)
Serial number: RTD
Binary serial number: 16843009 (0x01010101)
Manufacture year: 2021, Week: 1
VCP version: 2.2
I found a hardware solution using I2C 1 to control the Om Board HDMI (Primary output),
although this works it’s not a pretty solution.
Thanks for the detailed explanation and the results of your tests. Based on the behavior you described, the difference between the two HDMI paths is consistent with how the DDC channel is implemented and exposed by the HDMI controller on the Verdin module.
On the on-board HDMI output the DDC bus appears as /dev/i2c-6, identified as a DesignWare HDMI I2C adapter. In this configuration the system is able to read the EDID correctly, but the DDC/CI address 0x37 does not respond, so ddcutil reports that the monitor does not support DDC/CI. On the secondary HDMI output, where the monitor is accessed through /dev/i2c-1 (a regular SoC I²C controller), the same monitor reports VCP 2.2 and ddcutil works as expected. Since the monitor behaves correctly on that path, this confirms the issue is related to how the DDC channel is exposed on the primary HDMI interface rather than to the monitor itself.
On the Verdin iMX8M Plus the HDMI signal is generated directly by the NXP i.MX 8M Plus, which internally uses the Synopsys DesignWare HDMI controller. The DDC lines from the HDMI connector are handled by this controller, and the Linux DRM HDMI driver exposes the DDC engine to userspace as the “DesignWare HDMI I2C adapter”.
In practice this adapter is mainly intended for EDID retrieval and HDMI link management, and it is not always exposed as a fully generic I²C controller. Utilities such as ddcutil rely on full I²C functionality (for example combined transactions and repeated start conditions) to communicate with the monitor over DDC/CI. Some DesignWare HDMI implementations only partially support these operations through the DRM driver interface, which leads to the common pattern where EDID reads succeed but DDC/CI transactions fail.
There are also related discussions in the NXP community regarding DDC/CI support on i.MX8 HDMI paths and how the DDC channel is handled by the HDMI driver:
https://community.nxp.com/t5/i-MX-Processors/Device-Tree-To-Support-DDC-CI-For-HDMI-On-i-MX8/td-p/1445251
Because the HDMI interface on the Verdin module does not use an external HDMI bridge and the DDC channel is owned by the internal HDMI controller, there is no separate component that could be reconfigured to expose the bus differently. In that context, routing the DDC lines to a standard SoC I²C controller (as you did with I2C1) and using that bus for DDC/CI communication is a valid and robust solution when monitor control through DDC/CI is required.