- Jul 10, 2024
-
-
Olivier Fourdan authored
Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <!1602>
-
- Jul 09, 2024
-
-
Olivier Fourdan authored
Since commit 792758fa ("xwayland: Update lost focus on deactivation"), in rootful mode, if we receive an "activated" state from xdg-shell indicating that the surface is no longer active, we shall end up calling xwl_seat_leave_ptr(). But xwl_seat_leave_ptr() does not actually check whether the seat has pointer capabilities, and if not, get_pointer_device() will return NULL. As a result, we would crash using a NULL pointer in GetMaster(). This typically can happen when using Xwayland rootful on headless compositors such as "cage" which do not advertise any capabilities for the seat. To avoid the issue, simply check whether get_pointer_device() returns a valid non-null device and bail out early otherwise. Fixes: 792758fa - xwayland: Update lost focus on deactivation Closes: #1700 Signed-off-by:
-
- Jul 04, 2024
-
-
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:
-
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:
-
No functional change, this is just preparation work for the next commit. v2: Reshuffle functions (Michel) 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 intended, this is just preparation work for the next commit. 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:
-
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 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:
-
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:
-
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: -
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:
-
Make the (opaque) definition of the xwl_window_buffer generally available. No functional change. Signed-off-by:
-
If a child window of the same size is unmapped, we should stop walking the tree looking for the surface window to use. Whatever lies beneath is not visible anyway. This also fixes an issue with the Damage list becoming corrupted when destroying a window, because the first thing that DeleteWindow() does is to unmap the window and crush the window tree underneath it. Signed-off-by:
-
While walking the window tree looking for the surface window to use, we should ignore windows using manual redirection. If a client manually redirects a window, it has control over how the contents of that window are presented. It's not safe to present them directly to the Wayland compositor. v2: break instead of continue, reword commit message (Michel) Signed-off-by:
-
Function `xwl_glamor_gbm_init_main_dev` does not check whether `xwl_screen->default_feedback.main_dev` a.k.a. `main_dev` is a valid pointer. This result in some special situation where main linux-dmabuf device is not accessible, such as KWin nested desktop, raising segment fault. This commit add a null pointer check to prevent crashing. Signed-off-by:
Chenx Dust <chenx_dust@outlook.com> Closes: #1683 Fixes: d7f1909e - xwayland/glamor/gbm: make wl_drm optional See-also: https://bugzilla.redhat.com/2284141 (cherry picked from commit 76058333) Part-of: <!1569>
-
Noticed this after trying to update to xorg-server-xwayland-24.1.0 in void linux https://github.com/void-linux/void-packages/pull/50457 Signed-off-by:
Fotios Valasiadis <fvalasiad@gmail.com> (cherry picked from commit af6180b2) Part-of: <!1569>
-
Before this change, the xwayland pkgconfig file will always contain an includedir directive, even though xwayland is not a linkable shared library: prefix=/nix/store/3spcjqp5zcyg8arz6dnsj59fal5yk3jy-xwayland-23.2.6 includedir=${prefix}/include exec_prefix=${prefix} xwayland=/nix/store/3spcjqp5zcyg8arz6dnsj59fal5yk3jy-xwayland-23.2.6/bin/Xwayland […] Cflags: -I${includedir} According to a bug reporter this trips up cmake [1], which expects that the include directory exists, which it does not since xwayland does not install any header files. Add the dataonly directive to pkgsconfig.generate() which will remove the default "." subdir and ensures that includedir is not set inside the pkgconfig file. Additionally enforce the install directory to $libdir/pkgconfig, since it otherwise will be installed to $datadir/pkgconfig, which precludes programs from finding the pkgconfig because share/pkgconfig is usually not included in the search path. The resulting pkgconfig does not contain an includedir: prefix=/nix/store/p7xhdzl65hfhzf36vxykzp2i9cyy7y6c-xwayland-23.2.6 exec_prefix=${prefix} xwayland=/nix/store/p7xhdzl65hfhzf36vxykzp2i9cyy7y6c-xwayland-23.2.6/bin/Xwayland have_glamor=true have_eglstream=true have_initfd=true have_listenfd=true have_verbose=true have_terminate_delay=true have_no_touch_pointer_emulation=true have_force_xrandr_emulation=true have_geometry=true have_fullscreen=true have_host_grab=true have_decorate=false have_enable_ei_portal=true have_byteswappedclients=true Name: Xwayland Description: X Server for Wayland Version: 23.2.6 [1]: https://github.com/NixOS/nixpkgs/pull/309075#issuecomment-2108381428 Signed-off-by:Rouven Czerwinski <rouven@czerwinskis.de> Reviewed-by:
-
Signed-off-by:
Matthieu Herrb <matthieu@herrb.eu> (cherry picked from commit 89c3f35d) Part-of: <!1569>
-
- May 15, 2024
-
-
Olivier Fourdan authored
Xwayland 24.1.0 final release Signed-off-by:
-
- May 13, 2024
-
-
Olivier Fourdan authored
This restores the handling of the XRandR emulation for Xwayland rootless where it was before commit fa7b1c20. Some compositors may trigger a protocol error if the viewport source is larger than the actual window size, having that handled in the window resize hook makes sure we do not regress. Signed-off-by:
-
Olivier Fourdan authored
Commit fa7b1c20 ("xwayland: Use ConfigNotify screen hook instead of ResizeWindow") replaced the WindowResize hook with ConfigNotify. However, that's breaking rootful Xwayland with libdecor because the root window size is already set so the libdecor size is not updated, and the root size will be reverted back as soon as the focus changes. Reinstate the rootful size change in ResizeWindow to avoid that issue. Closes: #1669 Closes: #1671 Fixes: fa7b1c20 - xwayland: Use ConfigNotify screen hook instead of ResizeWindow Signed-off-by:
-
Olivier Fourdan authored
For now it just chains to ResizeWindow hook. This is preparation work for the next commit, no functional change. Signed-off-by:
-
This fixes the scroll action in Steam Input in SteamOS/Gamescope when using the new libeis backend. Fixes: a1333342 ("xwayland: Add XTEST support using EIS") Signed-off-by:
Joshua Ashton <joshua@froggi.es> (cherry picked from commit 7745fde2) Part-of: <xorg/xserver!1535>
-
In xwl_set_shape(), xwl_window_set_input_region() should be called only when the input shape of the toplevel window changes. However, given that xwl_window_from_window() is going to walk the ancestor tree until it finds an xwl_window, that lookup function cannot be used. Instead, xwl_window_get() should be used. It's going to return a valid xwl_window object iff the specified window has one associated with it. Fixes: a4ed100c - xwayland: Set wl_surface input region Closes: xorg/xserver#1672 Reviewed-by:
Vlad Zahorodnii <vlad.zahorodnii@kde.org> (cherry picked from commit 8c2b9f4e) Part-of: <xorg/xserver!1535>
-
- May 02, 2024
-
-
Olivier Fourdan authored
Xwayland 24.1.0 release candidate 2. Signed-off-by:
-
If multiple flips become ready for the same MSC, we would previously execute them all sequentially, one per MSC for sync flips. This could result in an unbounded flip queue and corresponding memory consumption. With implicit sync, leave the mailbox handling to the compositor for async flips though. v2: * Use present_vblank_rec::sync_flip. Closes: xorg/xserver#1664 Fixes: e1f16fb1 ("xwayland: don't scrap pending present requests") (cherry picked from commit 0d9a54aa) Part-of: <xorg/xserver!1494>
-
If a present request using explicit sync is scrapped, instead of sending a PresentIdleNotify event we should signal the release point. Signed-off-by:
Erik Kurzinger <ekurzinger@nvidia.com> (cherry picked from commit 80f74b0e) Part-of: <xorg/xserver!1494>
-
The functions xwl_glamor_dmabuf_import_sync_file and xwl_glamor_dmabuf_export_sync_file are used to ensure proper synchronization between clients using PresentPixmapSynced and compositors that do not support the wp_linux_drm_syncobj_v1 protocol when presenting by flipping. The acquire point's fence will be imported as the DMA-BUF's implicit fence before handing it off to the compositor, and then, after the DMA-BUF has been released, its new implicit fence will be exported and become the release point's fence which the client is expected to wait for before re-using the buffer. Both functions currently set the flags arguments of their respective ioctls to DMA_BUF_SYNC_READ. When importing a sync file, this means that any subsequent implicitly synchronized reads from the buffer will not wait for the fence, and when exporting a sync file it means that the returned fence may be signaled before preceeding reads from the buffer have completed. While this is correct for xwl_glamor_dmabuf_export_sync_file since the compositor will never write to the buffer, it is incorrect for xwl_glamor_dmabuf_import_sync_file. To avoid corruption, we need any reads from the buffer by the compositor to wait on the acquire point's fence. As a fix, instead of setting the DMA_BUF_SYNC_READ flag in xwl_glamor_dmabuf_import_sync_file, we set the DMA_BUF_SYNC_WRITE flag. This *does* provide the necessary guarantees. Signed-off-by:
-
Some applications that use client side decorations usually set custom input shape in order to prevent drop shadows stealing pointer events from windows below. Currently, the only way to get it is to use some XFixes APIs. On the other hand, plenty of wayland compositors use solely the wl_surface input region to decide what view can receive pointer input, which results in some pointer input issues around client side drop shadows because Xwayland doesn't set wl_surface.input_region. See-also: https://bugs.kde.org/show_bug.cgi?id=448119 Signed-off-by:
-
Olivier Fourdan authored
On DRM lease connector withdrawn event, Xwayland would free the corresponding xwl_output offered for lease. However, the pointer is still referenced from the rrLease->outputs[], meaning that trying to clean up the RANDR DRM leases as done with commit ef181265 (xwayland: Clean up drm lease when terminating) would cause a use after free and random crashes. To avoid that issue, on the connector withdraw event, set the connector withdrawn flag but do not to remove (i.e. free) the xwayland output if its is offered for lease. Then, once the lease is terminated, check for the xwl_outputs with a withdrawn connector and remove them (once we have no use for them anymore. Note that we cannot do that cleanup from xwl_randr_terminate_lease() as removing the xwl_output will free the RRcrtc resources, which checks for leases in XRANDR, and calls RRTerminateLease(), which chains back to xwl_randr_terminate_lease(). v2: Use a "withdrawn_connector" flag to mark outputs to remove (Xaver) Signed-off-by:
Xaver Hugl <xaver.hugl@kde.org> fixes: ef181265 - xwayland: Clean up drm lease when terminating See-also: xorg/xserver#946 See-also: xorg/xserver!1130 (cherry picked from commit 40537824) Part-of: <xorg/xserver!1494>
-
Olivier Fourdan authored
In xwl_randr_request_lease(), the code checks first for leased device, and then checks for existing output for lease. The former assumes there are outputs for lease whereas the latter checks for the output, connector and lease. So if there is any existing rrLease->outputs[]->devPrivate unset, the code would crash on a NULL pointer dereference on the first sanity check before having a chance to reach the second check that would have caught the problem. Invert the sanity checks so that we would catch this first and return a BadValue instead of possibly segfaulting. Signed-off-by:
-
Prevents Xwayland with glamor from logging unexpected depth: 15 to stderr many times when running rendercheck -t blend -o clear (cherry picked from commit 08113b89) Part-of: <xorg/xserver!1494>
-
Olivier Fourdan authored
Use the connector name as basis for the Xwayland output name in XRANDR, similar to what we do for regular outputs, instead of the generic "XWAYLAND<n>" name which changes every time the output is leased. Prefix the actual name with "lease-" to distinguish from duplicate names from the regular outputs. v2: avoid duplicate names (Simon) v3: Move the check for duplicates to xwl_output_set_name() (Simon) Signed-off-by:
-
Olivier Fourdan authored
Even though the name provided by either xdg-output or wl_output are guaranteed to be unique, that might not be the case with output names between different protocols, such as the one offered for DRM lease. To avoid running into name conflicts, check that no other existing output of the same name exists prior to changing the output name. Signed-off-by:
-
Olivier Fourdan authored
No functional change, this is preparation work for the next commit. Signed-off-by:
-
Olivier Fourdan authored
So that other parts of the Xwayland code can use it. Signed-off-by:
-
- Apr 18, 2024
-
-
Olivier Fourdan authored
Otherwise the executable cannot be found where specified. v2: Use 'xwayland_path' (Simon) Fixes: fbf5e26b - xwayland: Use full path for Xwayland exec Signed-off-by:
-
these m4 macros had been used for autotools-based build system. But since this had been replaced by meson, these files are obsolete now. Fixes: c97397dc Signed-off-by:
Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 887fc712)
Part-of: <xorg/xserver!1487>
-
