Top and bottom bar refers to player UI. When they disappear, playback is smooth.
DL3 devices are devices using DisplayLink's evdi and user mode driver.

Daniele, could this be related to explicit sync?

While playing YouTube video we can see corrupted frames when running fullscreen
mode with visible 'control' overlays. It is fine when those controls are hidden.

Here are timestamps in our atomic_flush function:

 No Overlays     |   Overlays
 ----------------+---------------------
 [ 1646.360...]  |   [ 1756.091...]
                 |   [ 1756.097...]
 [ 1646.394...]  |   [ 1756.124...]
                 |   [ 1756.133...]
 [ 1646.426...]  |   [ 1756.165...]
                 |   [ 1756.171...]
 [ 1646.460...]  |   [ 1756.192...]
                 |   [ 1756.200...]
 [ 1646.493...]  |   [ 1756.224...]
                 |   [ 1756.232...]
 [ 1646.527...]  |   [ 1756.259...]
                 |   [ 1756.264...]
 [ 1646.559...]  |   [ 1756.291...]
                 |   [ 1756.299...]
 [ 1646.594...]  |   [ 1756.325...]
                 |   [ 1756.332...]

It shows that without overlays we are getting quite stable framerate: 33ms per
frame. With them on the screen we are getting extra frame shortly after "normal"
one, around 6-9ms after. This extra one comes weirdly fast, out of sync, and
seems to be corrupted. It is new framebuffer and looks as like it is send in the
middle of rendering.

I checked the fences and it *looks* to be handled entirely by the kernel.
Fence is created in drm_atomic_plane_set_property (drm_atomic.c:750) and put
into the drm_plane_state. A bit later, in drm_atomic_helper_wait_for_fences
(drm_atomic_helper.c:1112) it is *consumed* by wait, destroyed and the pointer
is set to NULL. In our call to [plane]->atomic_update state->fence is NULL, so
nothing to wait for.

As an experiment I also tried to create another plane with OVERLAY type (simply
call to drm_universal_plane_init, with 0xFF as a crtc mask). Just to check if
this would change any behavior but its plane_update hook was never called.

I don't know what I am missing here. Is there something extra I shall do to
support OVERLAY plane or fences? Can you please give me a hint where to look?

@#3: It could be. We recently fixed an issue with explicit syncs and videos (http://crrev.com/a4298a95eccf85fc94c4fd686aa4b7021d08c5cd). Dawid, can you try to repro after that patch?

Additionally, can you try to disable explicit fences with the flag chrome://flags/#disable-explicit-dma-fences and see if the problem goes away?

Newly repo-synced image shows the same problems. Checked the suggested flag - it helped. When set to 'enabled' corruptions are not visible, when set to 'disabled' corruptions are visible.

dawid: Does the udl module claim to support drm atomic (https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?rcl=b94793dee2f9cca69c41f7f87f6fb4fef648bb3e&l=261) and explicit fences (https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/hardware_display_plane_atomic.cc?rcl=4d5ba645b78440b3c2109a029411d17db5be1e18&l=125)? Can you check if we're passing fences for each plane?

It'd be also interesting to know where the video frame is coming from, is that an HW video decoder or a SW one?

UDL is not atomic at all. As far as I know only explicit fences are supported only by atomic drivers so UDL does not support them.

Just to be sure we are on the same page: this issue is not about UDL but about EVDI driver.