On 11/29/2025 5:50 PM, Cristian Ciocaltea wrote: > Hi Chaoyi, > > On 11/29/25 5:49 AM, Chaoyi Chen wrote: >> Hello Cristian, >> >> On 11/28/2025 5:44 PM, Cristian Ciocaltea wrote: >>> The precision was something I initially looked into for CRC verification, >>> in the >>> context of the related IGT test. But since I've added the VKMS support, I >>> think >>> we should not worry about that anymore. >>> >>> Moreover, as already pointed out in [1], only RK3576 supports CRC >>> generation at >>> display controller level, and that is not particularly useful because it >>> doesn't >> >> I believe you can get the CRTC CRC on the RK3576, even when only the >> background is visible and all plane is disabled. Feel free to let me >> know if you run into any issues :) > > Yes, CRTC CRC works on RK3576 for the planes, but not for the background, i.e. > the CRC is not updated when setting a different background color. Unless > there's a way to change this default behavior, which I'm not aware of. > > My current understanding is that the background color is applied at a later > stage in the display pipeline, *after* blending the planes and computing CRC. >
Which CRTC are you using? If you're using VP0, you might run into this problem. Please try VP1 instead. >>> take the background color into account. Therefore I had to capture the >>> frame >>> CRCs at DisplayPort AUX channel level, by using the USB-C DP AltMode capable >> >> Oh that sounds interesting! I'm not sure how complex it would be to >> implement. > > That's already implemented, I plan to submit the patches soon. > >> >>> port of my RK3588-based board. However, that solution is not yet available >>> upstream, as it requires further work for cleanup and improving the overall >>> USB-C reliability. >>> >>> Hence I'll move on with your suggestion and switch to the simple >>> bit-shifting >>> approach for the next revision. >> > > -- Best, Chaoyi
