Re: [PATCH v3 4/4] drm/rockchip: vop2: Support setting custom background color

[Chaoyi Chen <chaoyi.chen@rock-chips.com>]

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