Hacker News Reader

Comment by alin23 | Hacker News Reader

I wonder if Alyssa (or other devs that took a deeper look at the DCP) have any idea why the builtin HDMI port of the Mac Mini would not send DDC messages to the connected monitor.

I’ve been struggling with this in Lunar (https://lunar.fyi) for a long time and while I tried my best by comparing ioreg dumps and looking at the DCP driver in IDA, I couldn’t find any obvious logic would block this communication voluntarily.

I should mention that on M1, the DDC messages are sent to the monitor by calling IOAVServiceWriteI2C on the DCPAVServiceProxy of the monitor as seen here: https://gist.github.com/alin23/b476a02a8cd298436848e28476aed...

I’m thinking that this logic might either exist in the DCP firmware which is not accessible from userspace, or it might just be a side effect of some out of spec behavior that the HDMI port might have.

View on HN

The DCP firmware has multiple endpoints. Currently, we only use and understand the main endpoint, which lacks raw I2C/DDC/EDID interfaces. Presumably this is available on another endpoint, but we haven't looked at this yet. Your gist gives me hope.

The HDMI port on the Mini is funny. The M1 supports exactly one internal display (the panel on a MacBook or iThing) and one external display (over DisplayPort/Thunderbolt). This is why M1 MacBooks can only drive a single external monitor.

For the Mini, the "internal" display is an internal DisplayPort connection, converted to HDMI with a mcdp29xx chip, and stuck on the HDMI port. Expect weirdness.

I thought it must be something related to the DisplayPort transport. I noticed in ioreg that the HDMI AppleCLCD2 had downstream=HDMI upstream=DP as its transport params.

So its possible that it isn’t DCP related after all, the mcdp29xx chip might not be implementing the DDC part at all like most USB-C hubs that I have to deal with.

Thanks for the insight!

It's worth noting that the MDCP29xx has its own DCP endpoint and proxy driver, so it likely implements its own DDC channel that way. Obviously, DCP itself needs to get the EDID one way or another. We'll see once we start looking into those add-on endpoints :)

I’ll keep a close eye on your work then!

I don’t have an M1 Mac Mini to do more thorough tests, but one Lunar user reported that the DDC set brightness command worked for a short second on the initial connection of the monitor.

So from that I’m guessing that the MDCP29xx keeps the DDC channel open until it gets the EDID and does whatever handshake is needed and then.. maybe it closes the channel?

Another weirdness anecdote is a user which reported that the DDC commands sent to the Thunderbolt-connected monitor were also sent to the HDMI monitor at the same time, but (as usual) writing directly to the HDMI monitor service did not do anything.

Could you maybe point me to where I should start looking for the MDCP29XX assembly? I previously looked at `/System/Library/Extensions/AppleMobileDispH13G-DCP.kext` but I’m thinking that what you’re talking about might not be a kext.

Thank you for making Lunar. I installed it right away and it's great.

Reply on news.ycombinator.com