From b0e41d802347773ed6d83a207e3f9f31a98825b9 Mon Sep 17 00:00:00 2001 From: Zoran Olujic Date: Mon, 9 Nov 2026 22:44:31 +0100 Subject: [PATCH] add notes from debugging DDC/CI on a Mac mini M4 A first-person write-up of the 29 October session: what the built-in HDMI port forwards, a USB-C to HDMI cable that drops DDC/CI, filler replies on DisplayPort, the mains power cycle that revived the monitor, and the double-write quirk. Linked from the guides index, the sitemap, and the troubleshooting guide. --- .github/workflows/pages.yml | 2 + documentation/ddc-ci-m4-mac-mini-notes.html | 229 ++++++++++++++++++++ documentation/ddc-ci-not-working.html | 2 +- documentation/guides.html | 5 + documentation/sitemap.xml | 6 +- 5 files changed, 242 insertions(+), 2 deletions(-) create mode 100644 documentation/ddc-ci-m4-mac-mini-notes.html diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml index a35a6c5..21dcb1b 100644 --- a/.github/workflows/pages.yml +++ b/.github/workflows/pages.yml @@ -49,6 +49,7 @@ jobs: cp documentation/external-monitor-brightness.html build/pages/external-monitor-brightness.html cp documentation/multi-monitor-control.html build/pages/multi-monitor-control.html cp documentation/ddc-ci-not-working.html build/pages/ddc-ci-not-working.html + cp documentation/ddc-ci-m4-mac-mini-notes.html build/pages/ddc-ci-m4-mac-mini-notes.html cp documentation/compare-mac-display-apps.html build/pages/compare-mac-display-apps.html cp documentation/support.html build/pages/support.html cp documentation/app-store-support.html build/pages/app-store-support.html @@ -141,6 +142,7 @@ jobs: test -s build/pages/external-monitor-brightness.html test -s build/pages/multi-monitor-control.html test -s build/pages/ddc-ci-not-working.html + test -s build/pages/ddc-ci-m4-mac-mini-notes.html test -s build/pages/compare-mac-display-apps.html test -s build/pages/support.html test -s build/pages/app-store-support.html diff --git a/documentation/ddc-ci-m4-mac-mini-notes.html b/documentation/ddc-ci-m4-mac-mini-notes.html new file mode 100644 index 0000000..ad80ce2 --- /dev/null +++ b/documentation/ddc-ci-m4-mac-mini-notes.html @@ -0,0 +1,229 @@ + + + + + + + + + DDC/CI on a Mac mini M4: HDMI, Adapters, and a Silent Monitor — Dimmerly + + + + + + + + + + + + + + + + + + + + + + + + +
+ Dimmerly + +
+ +
+ +

DDC/CI on a Mac mini M4: HDMI, adapters, and a silent monitor

+

My test Mac has one external monitor, and it ignored every DDC/CI command. m1ddc failed, and Dimmerly fell back to software dimming. On 29 October I went through the connection one piece at a time, mostly with read-only probes. These are the notes, in case your monitor is doing the same thing. If you just want your brightness slider back, start with the DDC/CI troubleshooting guide.

+ +
+
+ The cause + The monitor’s DDC/CI controller had stopped answering +
+
+ The fix + Unplugging the monitor from mains power for 1–2 minutes +
+
+ Not the cause + The Mac or the cables +
+
+ +
+

The setup

+
    +
  • Mac mini M4 on macOS 27.2.
    • +
  • Philips 276E8V, a 4K 27-inch monitor from 2019, with HDMI and DisplayPort inputs.
    • +
  • Three ways to connect it: the Mac’s built-in HDMI port, a USB-C to HDMI cable, and a USB-C to DisplayPort cable.
    • +
+

DDC/CI is a small I²C bus inside the video cable. The monitor’s DDC/CI controller listens at address 0x37. On Apple Silicon, apps don’t drive that bus themselves. They hand each request to the display coprocessor (DCP), which passes it on through whatever chip sits between the Mac and the monitor.

+

Every command-line tool gave the same answer at first:

+
+ 
$ m1ddc display 1 get luminance
+DDC communication failure: (iokit/?) unknown subsystem error
+
+
+ +
+

1. The built-in HDMI port forwards I²C

+

On M1 Macs and the entry-level M2 Mac mini, HDMI has a reputation for blocking DDC/CI. On this M4 the HDMI port goes through a Parade PS190 DisplayPort-to-HDMI converter, and macOS reports it as AppleDCPPS190. So I tested what gets through it.

+

Over the built-in port, the DCP read the monitor’s EDID (the block that identifies the monitor) at 0x50, its HDMI status registers (SCDC) at 0x54, and its HDCP receiver at 0x3a. Only the DDC/CI address stayed silent:

+
+ + + + + + + + + + + + + + + + +
AddressWhat lives thereResult
0x50EDIDRead correctly
0x54SCDC (HDMI status)Read correctly
0x3aHDCP 1.4 receiverRead correctly
0x37DDC/CI0xe0114000
0x49, 0x59Two devices I didn’t identifyAnswered
106 unused addressesNothing0xe0114000
+
+

The DDC/CI address returned exactly what an empty address returns: nothing acknowledged it. On its own, that code can’t say whether the monitor ignored 0x37 or the converter didn’t pass it on. The cable in the next section returns the same code without forwarding DDC/CI at all. What settled it was the power cycle in section 5. The HDMI port carries the monitor’s other I²C devices, but I haven’t yet changed brightness through it (see the end of this page).

+
+ +
+

2. A USB-C to HDMI cable that forwards only EDID

+

The USB-C to HDMI cable contains its own converter, a MegaChips MCDP2900, which macOS reports as AppleDCPMCDP2900. DDC/CI apps use 0xB7 instead of 0x37 for the MegaChips HDMI bridge built into some M1 and M2 Macs (AppleDCPMCDP29XX), so I tried both addresses.

+

Through this cable only EDID answered, at 0x50 and its alias 0xD0. A full scan of all 256 addresses found nothing else. The HDCP and SCDC devices that answered over the built-in port were gone, and both DDC/CI addresses returned the no-acknowledge code.

+

Later the same day, once the monitor was answering again, I tried the cable a second time. It still forwarded nothing at 0x37 or 0xB7. The picture is fine through it, but it doesn’t carry DDC/CI at all.

+
+ +
+

3. On DisplayPort, a missing reply can look like success

+

A USB-C to DisplayPort cable has no converter in the path. Over it, every address from 0x00 to 0xFF returned success. Apart from the real EDID at 0x50, the data was filler: the byte 0x5b repeated.

+

On a native DisplayPort connection, an unanswered I²C request comes back as a success with bytes that aren’t a reply, not as an error. m1ddc printed a brightness of 91, which is 0x5b read as a number. The brightness looked valid, but the monitor hadn’t answered.

+
+

If a DDC/CI tool reports the same odd value for every setting on DisplayPort, check whether it is 91 or 255 (0x5b or 0xff). A real DDC/CI reply carries a checksum. Dimmerly rejects any reply whose checksum doesn’t match, so filler bytes don’t turn into a brightness value.

+
+
+ +
+

4. What didn’t revive it

+
    +
  • A DDC/CI setting in the on-screen menu. This monitor doesn’t have one. The manual mentions DDC/CI only as a compatibility feature.
    • +
  • Resetting the on-screen menu to factory defaults. The filler bytes changed from 0x5b to 0xff, so something in the monitor reset, but DDC/CI stayed silent.
    • +
  • Switching the DisplayPort input from 1.1 to 1.2. The link went up from HBR to HBR2, and DDC/CI didn’t change.
    • +
+
+ +
+

5. What fixed it: mains power

+

I unplugged the monitor’s power cable for one to two minutes and plugged it back in. Over the DisplayPort cable it answered: brightness 100 of 100, contrast 50, volume 80. m1ddc worked, and Dimmerly listed the monitor’s hardware controls as Brightness, Contrast, Volume, and Input.

+

I’m not the first to see this. Someone with the same model reported in ddcutil issue #410 that it ignored DDC/CI until it was replugged and power-cycled, and then worked.

+

Dimmerly now suggests the power cycle itself. When the Mac reaches a monitor but the monitor never answers, Settings › Displays shows No DDC/CI reply. Unplug the monitor from power for a minute. I haven’t seen it appear on a silent monitor yet, because this one recovered before the hint existed. The DDC/CI troubleshooting guide has the same step.

+
+ +
+

6. Once awake, it ignores the first request

+

The revived monitor had one more quirk. A single request followed by a read never returned a fresh answer. The read returned the previous reply with a damaged header (6e 80 be), and its checksum failed. Sending the identical request twice, 10 to 50 ms apart, and then reading worked every time:

+
+ + + + + + + + + + + + +
SequenceFresh replies
One write, then read (waits of 50 or 150 ms, with or without a 10 ms pre-wait)0 of 6, in each variant
Two identical writes 10 ms apart, then read6 of 6
Two identical writes 50 ms apart, then read6 of 6
+
+

The read offset and read length made no difference. m1ddc already sends each request twice, and so does Dimmerly, which is why both worked once the monitor was awake.

+
+ +
+

7. Two DDC/CI tools at once make a working monitor look broken

+

One of my test runs failed 18 times out of 18 on a monitor that was working. Dimmerly was running in the background and talking to the same monitor, and the two programs’ requests and replies got interleaved on the bus. With Dimmerly quit, the double-write requests worked every time.

+

If you test with m1ddc or a similar tool, quit MonitorControl, Lunar, BetterDisplay, and Dimmerly first, or you’ll be measuring the collision.

+
+ +
+

What I’d check next time

+
    +
  1. If DDC/CI stopped working on a connection where it used to work, unplug the monitor from mains power for a minute before you buy a new cable.
    2. +
  2. Quit every other DDC/CI app before you test.
    3. +
  3. On DisplayPort, don’t trust a success code. Check that the reply has a valid checksum.
    4. +
  4. If a USB-C to HDMI cable passes only EDID, a USB-C to DisplayPort cable is the simplest way around it.
    5. +
+

One thing I haven’t checked yet: DDC/CI end to end over the built-in HDMI port with the revived monitor. The probes above show the port forwards I²C to the monitor, but I haven’t changed brightness through it yet. I’ll update this page when I do.

+

If you have a monitor, dock, or adapter that behaves differently, please open a monitor compatibility report.

+
+ Download Dimmerly + DDC/CI troubleshooting guide +
+
+
+ + + + + + diff --git a/documentation/ddc-ci-not-working.html b/documentation/ddc-ci-not-working.html index 32d87d4..4b9cb42 100644 --- a/documentation/ddc-ci-not-working.html +++ b/documentation/ddc-ci-not-working.html @@ -163,7 +163,7 @@

4. Worked yesterday, silent today

  • Wait one to two minutes.
  • Plug it back in and turn it on.
    • -

    Dimmerly checks the monitor again on its own and shows the cable icon once it answers.

    +

    Dimmerly checks the monitor again on its own and shows the cable icon once it answers. For one monitor where this was the fix, with the measurements, see DDC/CI on a Mac mini M4.

    diff --git a/documentation/guides.html b/documentation/guides.html index ffd198b..3828962 100644 --- a/documentation/guides.html +++ b/documentation/guides.html @@ -60,6 +60,11 @@

    External monitor brigh

    Find where DDC/CI stops: the monitor setting, a dock or adapter, the HDMI port, or a locked-up controller.

    Read the guide + +

    DDC/CI on a Mac mini M4: HDMI, adapters, and a silent monitor

    +

    Notes from one debugging session: what the HDMI port forwards, a cable that drops DDC/CI, and the power cycle that fixed the monitor.

    + Read the notes +

    Dimmerly, MonitorControl, Lunar, or BetterDisplay?

    What each app does, what it costs, and when another app is the better fit.

    diff --git a/documentation/sitemap.xml b/documentation/sitemap.xml index 7ab5dc5..93ec802 100644 --- a/documentation/sitemap.xml +++ b/documentation/sitemap.xml @@ -6,7 +6,7 @@ https://dimmerly.olujic.in.rs/guides.html - 2026-11-06 + 2026-11-09 https://dimmerly.olujic.in.rs/external-monitor-brightness.html @@ -20,6 +20,10 @@ https://dimmerly.olujic.in.rs/ddc-ci-not-working.html 2026-11-06 + + https://dimmerly.olujic.in.rs/ddc-ci-m4-mac-mini-notes.html + 2026-11-09 + https://dimmerly.olujic.in.rs/compare-mac-display-apps.html 2026-11-06