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.