A way to demonstrate this is with the following situation. Thi=
s assumes that
one has opened DRM and EGL devices.
- create a gbm surface with gbm_surface_create and usage GBM_BO_USE_LINEAR
- create an EGLSurface from the gbm surface with
eglCreatePlatformWindowSurfaceEXT
- render something to it using GLES
- get the resulting buffer using gbm_bo_lock_front_buffer
- attach it to the hardware cursor using drmModeSetCursor
- the cursor is not displayed
During these steps the following things happen in the DRM driver:
- when the surface is made current using eglMakeCurrent a new bo is created=
in
NOUVEAU_GBM_DOMAIN_GART (due to GBM_BO_USE_LINEAR)
- the rendering operations get queued (and may be flushed with glFlush(), i=
n my
specific case this didn't matter)
- when the bo is attached to the cursor plane, it is moved to
NOUVEAU_GBM_DOMAIN_VRAM. If the rendering operations haven't finished at th=
is
point, the copied buffer is empty.
Note that since this is a timing issue it might not be reproducible in all
situations.=20
This was tested on different GPUs (GTX 1080 and GT 445M) with rootston (wlr=
oots
example wayland compositor: h=
ttps://github.com/swaywm/wlroots , git commit
b2f56ad4) running weston-terminal (this makes the issue appear more frequen=
tly)
Probably the driver should wait for pending rendering operations on the sur=
face
before moving it around. Another possibility for the scenario listed above =
is
to let the bo start in VRAM, so no moves are necessary. In order to prevent
other setups from breaking this would then only be done if GBM_BO_USE_SCANO=
UT
was set on creation. A workaround is to add glFinish() in the application
before calling drmModeSetCursor.
Kernel version: 4.20.6
Mesa version: 18.3.3