I wish I had the expertise to do such in-depth reverse engineering of firmware blobs. The DCP is actually the thing that's stopping me from providing native br

I wish I had the expertise to do such in-depth reverse engineering of firmware blobs. The DCP is actually the thing that's stopping me from providing native brightness control on the HDMI port of the newer Macs inside Lunar (https://lunar.fyi https://lunar.fyi). Users have to either switch to a Thunderbolt port to get native brightness control for their monitor, or use a software dimming solution like Gamma Table alteration. It's not clear what's going on, but it seems that the HDMI port of the 2018+ Macs uses an MCDP29xx chip inside, which converts the HDMI signal to DisplayPort internally, so that Apple doesn't have to decode both HDMI and DP video signals. (that is also the reason why even the newest MacBook and Mac Studio have only HDMI 2.0, that's the most the converter chip supports [0]) When sending DDC commands through the IOAVServiceWriteI2C call, monitors connected to the HDMI port lose video signal, or flicker or completely crash and need a power cycle to get them back. The Thunderbolt ports however send the DDC command as expected when IOAVServiceWriteI2C is called After @marcan42 from Asahi Linux pointed out [1] the DCPAVFamilyProxy kexts, I've looked into it and I found some different writei2c methods and some MCDP29xx specific code, but no clue on how to call them from userspace. I guess I'll have to look into how the analysed exploit is using the RPC, and also check the methods assembly from inside the firmware blob itself. I was not aware that most userspace methods are now shims for remotely calling the embedded code. [0] https://www.kinet-ic.com/mcdp2900/ https://www.kinet-ic.com/mcdp2900/ [1] https://twitter.com/marcan42/status/1483283365407371265 https://twitter.com/marcan42/status/1483283365407371265