Open Nikilee1228 opened 2 weeks ago
Hi @Nikilee1228 , this app is used for demo purpose, what is the value you are expecting the panel to actually return?
as the note in the sample code(I2C_AUX_Sample_App.cpp). it should return 11 bytes and the 10th byte value is current brightness value of the panel. If it is a driver or panel issue, the ctlInit function should return an error, and the program wouldn't even reach the write and read functions for I²C. Therefore, I want to confirm whether there is any mistake in the demo sample code, causing it to return 6E 80, which indicates a error or an unsupported command.
// I2C WRITE : 82 01 10 AC at adddress 6E and subaddress 51 // If we write these BYTEs ( 82 01 10 AC) to adddress 6E and // subaddress 51, it should update the current brightness to the 10th // byte at adddress 6E and subaddress 51. One can verify by changing // panel brightness from panel buttons and the writing to adddress 6E // and subaddress 51 ( 82 01 10 AC), and then reading 10th byte at // adddress 6E and subaddress 51. For Example : The following 11 byte // values should be shown by the I2C Read post I2C write. Values are // 6E 88 02 00 10 00 00 64 00 19 D9. (If HDMI panel brightness is set // to 25%) 10th byte value is current brightness value of the // panel.To confirm that value is correct or not, convert the Hex // value to Decimal.
I think you are mis-reading the example. This is following MCCS sequence to read brightness from the panel, Refer below
6E Destination address 51 Source address 82 Length 01 Get VCP Feature COMMAND 10 - CP VCP opcode for reading luminance value from the panel AC - CHKsum to of the payload sent
This will simply read the current brightness from the panel. To get exactly same value as sample app, you might have to go to your panel, set the brightness to 25%, then run the same app. It should return 0x19 (25) in 10th byte.
Thats how we should interpret the return values.
return values should be interpreted differently
6E Destination address 51 Source address 82 Length 02 VCP Feature reply op code 00 RC Result Code 00h NoError 01h Unsupported VCP Code xx CP VCP opcode from Feature request message xx TP VCP type code
etc...
Please go through MCCS spec from VESA for further details.
@Nikilee1228 , is this resolved for you now?
Thank you for your response. However, I’m sorry to say that it didn’t solve my issue. I understand the content transmitted via MCCS, but my question is regarding the use of your demo code (I2C_AUX_Sample_App.exe). After running it, I only receive 6E 80 BE, just like the screenshot I provided.
No matter how I adjust the brightness of the external monitor, even if I set it to 25% as you suggested, the result remains the same. I have analyzed the situation:
If it were a laptop issue, such as an incompatible Intel driver version, the initial function should have failed, but as shown in the screenshot, it did not.
If the external monitor didn’t support I2C, I shouldn’t receive any response at all, not even a value.
If the issue were with the connection cable (USB-C), the third-party tool I used to read VCP shouldn’t have worked, but it did.
So, I wanted to ask, when you wrote this demo code, what cable and computer setup did you use for testing? Or is there anything else I could try?
Thanks again for helping.
It seems to be like a monitor problem rather than cable issue. RC - result code should come as 00 MCCS is generally not implemented on all monitors the same way.
We had used some older DP monitors when we developed this code.
Running the I2C_AUX_Samples.exe , Got 0x6E 0x80 0xBE Response. My Laptop: ThinkBook 16p Gen4 CPU: 13th Gen Intel Core i9-13900 OS: Windows 11 Connection: Type-C cable to an external monitor (Type-C Alt Mode)
Attached the result pic.