Commits on Source (12)
-
Make the (opaque) definition of the xwl_window_buffer generally available. No functional change. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1571>
-
We want to decorrelate the explicit buffer synchronization from the window buffers, and move that to the GLAMOR/GBM code instead. To do that, we need to be able to invoke the xwl_window_buffer's release_callback() routine from outside the window buffer code. For that purpose, introduce xwl_window_buffer_release() which calls xwl_window_buffer_release_callback() for us. This is preparation work for the following changes, no functional change intended at this point. Signed-off-by:
-
Copy the code to deal with synchronization objects from the window buffers to the GLAMOR/GBM code. The idea is to deal with synchronizations for all pixmaps, even when there is no window buffer involved. This is still preparation work for the following commits, no functional change intended at this point. v2: Use a "xwl_window_buffer *" instead of a "void *data" (Michel) v3: Bail early if there's no xwl_window_buffer (Michel) v4: Rename xwl_window_submit_pixmap() to xwl_glamor_gbm_wait_release_fence() (Michel) Signed-off-by: -
Now that we have the buffer synchronization implemented in the GLAMOR/GBM code, switch to use that code. At this point, there is still not functional change intended, this is still preparation work for a fix that is still to come. Signed-off-by:
-
The function xwl_window_swap_pixmap() can be called from two places, either from xwl_window_attach_buffer() or from damage_report(). When called from xwl_window_attach_buffer(), the new buffer is attached and the surface committed. However, when called from damage_report(), a new buffer might not be attached before the surface is committed. That's fine with implicit synchronization, but if we use explicit synchronization, committing a surface without a new buffer attached but with a release timeline point set is a protocol error: | If at surface commit time there is a pending release timeline point | set but no pending buffer attached, a no_buffer error is raised. To avoid such an issue, add a new parameter to xwl_window_swap_pixmap() to hint whether it should set the synchronization points, and have the synchronization points set only from xwl_window_attach_buffer(). v2: Rename param to handle_sync (Michel) Suggested-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
-
Move the code which takes care of submitting pixmaps and the synchronization points to its own function. This will allow to reuse that code from different code path. No functional change intended. Signed-off-by:
-
The wp_linux_drm_syncobj_v1 protocol states that : | If at surface commit time there is a pending buffer attached but no | pending release timeline point set, the no_release_point protocol | error is raised. So we need to set a release timeline point in any case from the swap pixmap routine, even for the early out code paths. Failing to do so may cause a Wayland protocol error that is fatal to the Wayland client, in this case Xwayland: | wp_linux_drm_syncobj_surface_v1: error 4: No Acquire point provided | (EE) failed to dispatch Wayland events: Protocol error Closes: xorg/xserver#1688 Fixes: 87bf2caf - xwayland: add support for wp_linux_drm_syncobj_v1 Signed-off-by:
-
No functional change intended, this is just preparation work for the next commit. Signed-off-by:
-
Right now, we would dispose the xwl_window and all the data associated with it on unrealize. But not all window destruction go through the unrealize code path, for example when the root window (running rootful) is destroyed from the resource manager on server reset, we do not get to the unrealize window step, but straight to destroy window. As a result, we are leaking the xwl_window and all the data associated with it, for example: | 65,536 bytes in 1 blocks are possibly lost in loss record 12,462 of 12,488 | at 0x484A0FC: calloc (vg_replace_malloc.c:1675) | by 0x48B661C: UnknownInlinedFun (pixman-bits-image.c:1273) | by 0x48B661C: _pixman_bits_image_init (pixman-bits-image.c:1296) | by 0x48B6754: create_bits_image_internal (pixman-bits-image.c:1349) | by 0x64180DE: UnknownInlinedFun (cairo-image-surface.c:380) | by 0x64180DE: UnknownInlinedFun (cairo-image-surface.c:366) | by 0x64180DE: cairo_image_surface_create (cairo-image-surface.c:432) | by 0x6346B44: UnknownInlinedFun (libdecor-gtk.c:467) | by 0x6346B44: libdecor_plugin_gtk_frame_new (libdecor-gtk.c:546) | by 0x4B7F297: libdecor_decorate (libdecor.c:559) | by 0x42C6F3: xwl_create_root_surface (xwayland-window.c:1266) | by 0x42CD97: ensure_surface_for_window (xwayland-window.c:1466) | by 0x42D0D1: xwl_realize_window (xwayland-window.c:1560) | by 0x50858F: compRealizeWindow (compwindow.c:279) | by 0x4FF2A2: MapWindow (window.c:2706) | by 0x4F9E7F: InitRootWindow (window.c:697) To avoid that issue, check whether there is still an xwl_window associated with the X11 window on destroy, and if that's the case, dispose the xwl_window. Signed-off-by:
-
No functional change, this is just preparation work for the next commit. v2: Reshuffle functions (Michel) Signed-off-by:
-
For cases (to come) where we would want to force the disposal of the window buffers, add a parameter to force the disposal by calling dispose() directly instead of maybe_dispose(). Signed-off-by:
-
With explicit buffer synchronization in use, the window buffers use a file descriptor for event notification to keep the buffer alive for synchronization purpose. When running rootful, the root window (which is visible) is destroyed directly from the resource manager on server reset, and the window buffer's eventfd will trigger after the window is destroyed, leading to a use after free and a crash of the xserver. To avoid the issue, check whether the window being destroyed is the root window in rootless mode, and make sure to force the disposal of the window buffers in that case. Signed-off-by:
Showing
- hw/xwayland/xwayland-dmabuf.c 1 addition, 1 deletionhw/xwayland/xwayland-dmabuf.c
- hw/xwayland/xwayland-glamor-gbm.c 144 additions, 0 deletionshw/xwayland/xwayland-glamor-gbm.c
- hw/xwayland/xwayland-glamor-gbm.h 8 additions, 0 deletionshw/xwayland/xwayland-glamor-gbm.h
- hw/xwayland/xwayland-types.h 1 addition, 0 deletionshw/xwayland/xwayland-types.h
- hw/xwayland/xwayland-window-buffers.c 62 additions, 105 deletionshw/xwayland/xwayland-window-buffers.c
- hw/xwayland/xwayland-window-buffers.h 3 additions, 4 deletionshw/xwayland/xwayland-window-buffers.h
- hw/xwayland/xwayland-window.c 36 additions, 25 deletionshw/xwayland/xwayland-window.c