I am playing with IOI2CSendRequest and found a couple things I cannot do with it:
-
E-DDC read of EDIDs that are longer than 256 bytes. This requires a transaction with two sends (one for the segment pointer and one for the offset) with a start bit before each and then the reply preceded by a start bit and ended by a stop bit. IOI2CSendRequest can only do one send and one reply in a single transaction. The E-DDC transaction cannot be split because a second transaction would add an extra stop bit which would reset the segment pointer. A transaction without the offset part works with the GTX 680 or Intel UHD 630 but not with the AMD W5700.
-
DisplayPort DPCD read from DisplayPort device connected to a DisplayPort branch device. This requires a send to the sideband message down request buffer and a reply from the sideband message down reply buffer. This cannot be done with a single IOI2CSendRequest send and reply because the reply is not immediate. I don't think the reply can be polled because I think that is handled by a DisplayPort interrupt and the reply is probably read by the GPU driver and not passed to the user client.
Is there a special way to setup the IOI2CRequest to do the above?
In the E-DDC case, the i2c handler could maybe suppress the stop bit of the first send after it recognizes that the send is for the segment pointer.
In the DisplayPort sideband case, the i2c handler could recognize that the user client wants to get a reply from a sideband message by examining the request sent in the contents of the DisplayPort send buffer, and should therefore queue up the request and wait for the reply.
What about M1 Macs? I understand there are some undocumented APIs that people are using to do DDC/CI (MCCS) or to read the EDID but I don't know if they can get more than 256 bytes of the EDID.