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