Thomas Zimmermann <tzimmermann@xxxxxxx> writes:
> Hi
>
> Am 09.11.23 um 18:24 schrieb Javier Martinez Canillas:
[...]
>> struct drm_rect src;
>> memset(iter, 0, sizeof(*iter));
>> @@ -223,7 +224,8 @@ __drm_atomic_helper_damage_iter_init(struct drm_atomic_helper_damage_iter *iter,
>> iter->plane_src.x2 = (src.x2 >> 16) + !!(src.x2 & 0xFFFF);
>> iter->plane_src.y2 = (src.y2 >> 16) + !!(src.y2 & 0xFFFF);
>>
>> - if (!iter->clips || !drm_rect_equals(&state->src, &old_state->src)) {
>> + if (!iter->clips || !drm_rect_equals(&state->src, &old_state->src) ||
>> + (buffer_damage && old_state->fb != state->fb)) {
>
> I'd assume that this change effectivly disables damage handling. AFAICT
> user space often does a page flip with a new framebuffer plus damage
> data. Now, with each change of the framebuffer we ignore the damage
> information. It's not a blocker as that's the behavior before 6.4, but
> we should be aware of it.
>
Yes, which is the goal of this patch since page flip with a new framebuffer
attached to a plane plus damage information can't be supported by drivers
that do per-buffer uploads.
This was causing some weston and wlroots to have flickering artifacts, due
the framebuffers being changed since the last plane update.
For now it was decided with Sima, Simon and Pekka that is the best we can
do and the reason why I add a TODO in patch #6.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
