- May 02, 2024
-
-
Olivier Fourdan authored
Xwayland 24.1.0 release candidate 2. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1513>
-
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:
Erik Kurzinger <ekurzinger@nvidia.com> (cherry picked from commit d5192ba8) Part-of: <xorg/xserver!1494>
-
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:
Vlad Zahorodnii <vlad.zahorodnii@kde.org> Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit a4ed100c) Part-of: <xorg/xserver!1494>
-
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:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-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:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Xaver Hugl <xaver.hugl@kde.org> (cherry picked from commit 21916ae1) Part-of: <xorg/xserver!1494>
-
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 <ofourdan@redhat.com> (cherry picked from commit 49b8f131) Part-of: <xorg/xserver!1494>
-
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 <ofourdan@redhat.com> (cherry picked from commit d36f66f1) Part-of: <xorg/xserver!1494>
-
Olivier Fourdan authored
No functional change, this is preparation work for the next commit. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 0cb4ec4d) Part-of: <xorg/xserver!1494>
-
Olivier Fourdan authored
So that other parts of the Xwayland code can use it. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 12265aaa) Part-of: <xorg/xserver!1494>
-
- 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:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 8ff88ffe) Part-of: <xorg/xserver!1494>
-
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>
-
- Apr 17, 2024
-
-
Olivier Fourdan authored
Xwayland 24.1.0 release candidate 1. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1489>
-
- Apr 12, 2024
-
-
Olivier Fourdan authored
In preparation for a 24.1 release. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1483>
-
(cherry picked from commit 001f0c89) Part-of: <xorg/xserver!1483>
-
We're keeping it for unit tests, but we don't want to ship it from this branch. Also disable Xvfb in CI for ninja test. It's still built and used for unit tests as part of ninja dist, but we don't want to run XTS on Xvfb. (cherry picked from commit 0408fcb3) Part-of: <xorg/xserver!1483>
-
Not used on this branch. (cherry picked from commit aa49cd5a) Part-of: <xorg/xserver!1483>
-
Not used anymore on this branch. (cherry picked from commit 23296633) (cherry picked from commit d07af46a) Part-of: <xorg/xserver!1483>
-
(cherry picked from commit 8f480147) This partly reverts commit d3933a24. Part-of: <xorg/xserver!1483>
-
(cherry picked from commit 69cc6a6c) Part-of: <xorg/xserver!1483>
-
(cherry picked from commit 6cae4b39) Part-of: <xorg/xserver!1483>
-
In xwl_source_validate(), the actual box wasn't updated, so we would possibly copy several times the same first box. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Fixes: aa05f38f - xwayland: Add SourceValidate hook Part-of: <xorg/xserver!1485>
-
Fixes leak: ==15672== 60 bytes in 1 blocks are definitely lost in loss record 3,803 of 8,127 ==15672== at 0x4840718: malloc (vg_replace_malloc.c:392) ==15672== by 0x2F2698: XNFreallocarray (alloc.c:55) ==15672== by 0x1ADAA9: xwl_dmabuf_get_formats_for_device (xwayland-dmabuf.c:207) ==15672== by 0x1ADAA9: xwl_glamor_get_formats (xwayland-dmabuf.c:248) ==15672== by 0x303D86: cache_formats_and_modifiers (dri3_screen.c:176) ==15672== by 0x303D86: dri3_get_supported_modifiers (dri3_screen.c:229) ==15672== by 0x30331A: proc_dri3_get_supported_modifiers (dri3_request.c:389) ==15672== by 0x217B6B: Dispatch (dispatch.c:550) ==15672== by 0x21B9A0: dix_main (main.c:276) ==15672== by 0x51086C9: (below main) (libc_start_call_main.h:58) Fixes: a42992a4 ("dri3: rework format/modifier caching") Part-of: <!1484>
-
xwl_dmabuf_feedback_tranche_target_device always allocates a new drmDevice for xwl_feedback->tmp_tranche.drm_dev, so the pointers are never equal here. Fixes: 6f0b9dee ("xwayland: use drmDevice to compare DRM devices") v2: * Flip order of checks, so drmDevicesEqual is called only if the supports_scanout flags match. Part-of: <xorg/xserver!1484>
-
Fixes leaks: ==13712== 144 bytes in 1 blocks are definitely lost in loss record 4,827 of 7,462 ==13712== at 0x48459F3: calloc (vg_replace_malloc.c:1340) ==13712== by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072) ==13712== by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104) ==13712== by 0x49BFAC9: process_device (xf86drm.c:4508) ==13712== by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670) ==13712== by 0x1AD370: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477) ==13712== by 0x53C03FD: ffi_call_unix64 (unix64.S:104) ==13712== by 0x53BF70C: ffi_call_int (ffi64.c:673) ==13712== by 0x53BFEE2: ffi_call (ffi64.c:710) ==13712== by 0x49AC920: wl_closure_invoke (connection.c:1025) ==13712== by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631) ==13712== by 0x49AA5AB: dispatch_queue (wayland-client.c:1777) ==13712== by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019) ==13712== by 0x49AAB5E: wl_display_roundtrip_queue (wayland-client.c:1403) ==13712== 576 bytes in 4 blocks are definitely lost in loss record 6,289 of 7,462 ==13712== at 0x48459F3: calloc (vg_replace_malloc.c:1340) ==13712== by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072) ==13712== by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104) ==13712== by 0x49BFAC9: process_device (xf86drm.c:4508) ==13712== by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670) ==13712== by 0x1AD583: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477) ==13712== by 0x1AD583: xwl_window_dmabuf_feedback_main_device (xwayland-dmabuf.c:691) ==13712== by 0x53C03FD: ffi_call_unix64 (unix64.S:104) ==13712== by 0x53BF70C: ffi_call_int (ffi64.c:673) ==13712== by 0x53BFEE2: ffi_call (ffi64.c:710) ==13712== by 0x49AC920: wl_closure_invoke (connection.c:1025) ==13712== by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631) ==13712== by 0x49AA5AB: dispatch_queue (wayland-client.c:1777) ==13712== by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019) ==13712== by 0x1A1842: xwl_read_events (xwayland-screen.c:566) ==13712== by 0x1A1842: xwl_read_events (xwayland-screen.c:553) Fixes: 6f0b9dee ("xwayland: use drmDevice to compare DRM devices") Part-of: <xorg/xserver!1484>
-
- Apr 11, 2024
-
-
Balló György authored
Instead of thowing fatal error on GLSL link failure, fall back to software rendering. This allows using Glamor on systems with limited hardware resources (such as i915). Part-of: <xorg/xserver!1173>
-
There are a number of regressions and hard to reproduce issues that find their roots in this change, so revert it until those can be ironed out some more. This reverts commit 4bb1f976. Closes: #1655 Closes: #1656 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <!1457>
-
hw/xwayland/xwayland-glamor-gbm.c:38:10: fatal error: 'linux/dma-buf.h' file not found 38 | #include <linux/dma-buf.h> | ^~~~~~~~~~~~~~~~~ Fixes: 3df236a3 ("xwayland: add functions to import and export dma-buf implicit fences") Part-of: <xorg/xserver!1481>
-
- Apr 10, 2024
-
-
It's needed when the surface window is a depth 24 descendant of a depth 32 toplevel window. xwl_source_validate ensures the toplevel window pixmap has valid contents when a client reads from it, or when the window hierarchy / geometry changes. It's never called in the normal fullscreen application case, so there's no GPU copy overhead with that. v2: * Don't try to redirect a depth 32 descendant of different-depth ancestors, the alpha channel wouldn't be handled correctly. (Olivier Fourdan) Part-of: <xorg/xserver!1300>
-
Preparation for next commit, no functional change intended. Part-of: <xorg/xserver!1300>
-
A later commit will use it to ensure the toplevel window pixmap has valid contents. It's hooked up only while any xwl_window->surface_window_damage points to a non-empty region. So far it's always NULL, so no functional change intended. v2: * Fix trailing whitespace. (Olivier Fourdan) v3: * Use toplevel local variable more in xwl_window_update_surface_window. Part-of: <xorg/xserver!1300>
-
A later commit will use these to (un)redirect the surface window on demand. Not used yet, so no functional change intended. v2: * Use "surface_window_damage" instead of "surf_win_damage". (Olivier Fourdan) * Slightly simplify logic in xwl_unrealize_window. v3: * Add comment in xwl_present_maybe_unredirect_window explaining why we use a timer. (Olivier Fourdan) v4: * Rename unredir_timer field to unredirect_timer. Part-of: <xorg/xserver!1300>
-
Preparation for later commits, no functional change intended. Part-of: <xorg/xserver!1300>
-
It may track a non-toplevel window which fully covers the area of the window pixmap / Wayland surface. It is now used instead of xwl_window::toplevel for updating the Wayland surface contents. The surface_window can now hit the Present page flip path while it's automatically redirected. v2: * Use "surface_window" instead of "surf_win". (Olivier Fourdan) * Add comment describing surface_window, and describe what surface_window/toplevel are useful for respectively. (Olivier Fourdan) * Use surface_window in xwl_realize_window. v3: * Backtrack up to the closest opaque ancestor in xwl_window_update_surface_window. (Olivier Fourdan) v4: * Clean up logic for determining the surface window in xwl_window_update_surface_window, and document it better. * Handle window_get_damage(xwl_window->surface_window) returning NULL in xwl_window_update_surface_window. * Call xwl_window_update_surface_window after xwl_window_buffers_init in ensure_surface_for_window, since the former may call xwl_window_buffers_dispose. * Rename surf/win_pix to surface/window_pixmap in xwl_window_update_surface_window. Part-of: <xorg/xserver!1300>
-