3 ms·
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 transpor
by alin23 5y ago
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!
- marcan_42 5y agoIt'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 :)
- alin23 5y agoI’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.