Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with I²C Access Sample Code on External Monitor via Type-C Connection (0x6E 0x80 0xBE Response) #99

Open
Nikilee1228 opened this issue Oct 17, 2024 · 6 comments

Comments

@Nikilee1228
Copy link

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.
result

@murali-i
Copy link
Contributor

Hi @Nikilee1228 , this app is used for demo purpose, what is the value you are expecting the panel to actually return?

@Nikilee1228
Copy link
Author

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.

@murali-i
Copy link
Contributor

murali-i commented Oct 19, 2024

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.

@murali-i
Copy link
Contributor

@Nikilee1228 , is this resolved for you now?

@Nikilee1228
Copy link
Author

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.

@murali-i
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants