- 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>
-
Preparation for later changes, no functional change intended. Part-of: <!1300>
-
Preparation for later commits, no functional change intended. Part-of: <xorg/xserver!1300>
-
Preparation for next commit. This might change behaviour for non-InputOutput top-level windows. ensure_surface_for_window getting called and returning non-NULL for those would seem like a pre-existing bug though. Part-of: <xorg/xserver!1300>
-
Preparation for later commits, no functional change intended. v2: * Leave register_damage call unchanged in this commit. (Olivier Fourdan) Part-of: <xorg/xserver!1300>
-
It's always the toplevel window, i.e. either the root window or a child of it. Preparation for later commits, no functional change. v2: (Olivier Fourdan) * Fix debug build. * Add comment describing ::toplevel. Part-of: <xorg/xserver!1300>
-
Slightly simpler, and might work better in some cases when X windows get reparented. Part-of: <!1300>
-
Fix compiler warnings: ../hw/xfree86/os-support/bsd/bsd_VTsw.c: In function ‘xf86VTSwitchPending’: ../hw/xfree86/os-support/bsd/bsd_VTsw.c:56:1: warning: old-style function definition [-Wold-style-definition] 56 | xf86VTSwitchPending() | ^~~~~~~~~~~~~~~~~~~ ./hw/xfree86/os-support/bsd/bsd_VTsw.c: In function ‘xf86VTSwitchAway’: ./hw/xfree86/os-support/bsd/bsd_VTsw.c:67:1: warning: old-style function definition [-Wold-style-definition] 67 | xf86VTSwitchAway() | ^~~~~~~~~~~~~~~~ ../hw/xfree86/os-support/bsd/bsd_VTsw.c: In function ‘xf86VTSwitchTo’: ../hw/xfree86/os-support/bsd/bsd_VTsw.c:82:1: warning: old-style function definition [-Wold-style-definition] 82 | xf86VTSwitchTo() | ^~~~~~~~~~~~~~ ../hw/xfree86/os-support/bsd/bsd_init.c: In function ‘xf86OpenConsole’: ../hw/xfree86/os-support/bsd/bsd_init.c:153:1: warning: old-style function definition [-Wold-style-definition] 153 | xf86OpenConsole() | ^~~~~~~~~~~~~~~ ../hw/xfree86/os-support/bsd/bsd_init.c: In function ‘xf86OpenPccons’: ../hw/xfree86/os-support/bsd/bsd_init.c:320:1: warning: old-style function definition [-Wold-style-definition] 320 | xf86OpenPccons() | ^~~~~~~~~~~~~~ ../hw/xfree86/os-support/bsd/bsd_init.c: In function ‘xf86OpenPcvt’: ../hw/xfree86/os-support/bsd/bsd_init.c:451:1: warning: old-style function definition [-Wold-style-definition] 451 | xf86OpenPcvt() | ^~~~~~~~~~~~ ../hw/xfree86/os-support/bsd/bsd_init.c: In function ‘xf86OpenWScons’: ../hw/xfree86/os-support/bsd/bsd_init.c:563:1: warning: old-style function definition [-Wold-style-definition] 563 | xf86OpenWScons() | ^~~~~~~~~~~~~~ ../hw/xfree86/os-support/bsd/bsd_init.c: In function ‘xf86CloseConsole’: ../hw/xfree86/os-support/bsd/bsd_init.c:594:1: warning: old-style function definition [-Wold-style-definition] 594 | xf86CloseConsole() | ^~~~~~~~~~~~~~~~ ../hw/xfree86/os-support/bsd/bsd_init.c: In function ‘xf86UseMsg’: ../hw/xfree86/os-support/bsd/bsd_init.c:671:1: warning: old-style function definition [-Wold-style-definition] 671 | xf86UseMsg() | ^~~~~~~~~~ Signed-off-by:
Enrico Weigelt, metux IT consult <info@metux.net> Part-of: <xorg/xserver!1445>
-
- Apr 09, 2024
-
-
ProcRenderAddGlyphs() adds the glyph to the glyphset using AddGlyph() and then frees it using FreeGlyph() to decrease the reference count, after AddGlyph() has increased it. AddGlyph() however may chose to reuse an existing glyph if it's already in the glyphSet, and free the glyph that was given, in which case the caller function, ProcRenderAddGlyphs() will call FreeGlyph() on an already freed glyph, as reported by ASan: READ of size 4 thread T0 #0 in FreeGlyph xserver/render/glyph.c:252 #1 in ProcRenderAddGlyphs xserver/render/render.c:1174 #2 in Dispatch xserver/dix/dispatch.c:546 #3 in dix_main xserver/dix/main.c:271 #4 in main xserver/dix/stubmain.c:34 #5 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #6 in __libc_start_main_impl ../csu/libc-start.c:360 #7 (/usr/bin/Xwayland+0x44fe4) Address is located 0 bytes inside of 64-byte region freed by thread T0 here: #0 in __interceptor_free libsanitizer/asan/asan_malloc_linux.cpp:52 #1 in _dixFreeObjectWithPrivates xserver/dix/privates.c:538 #2 in AddGlyph xserver/render/glyph.c:295 #3 in ProcRenderAddGlyphs xserver/render/render.c:1173 #4 in Dispatch xserver/dix/dispatch.c:546 #5 in dix_main xserver/dix/main.c:271 #6 in main xserver/dix/stubmain.c:34 #7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 previously allocated by thread T0 here: #0 in __interceptor_malloc libsanitizer/asan/asan_malloc_linux.cpp:69 #1 in AllocateGlyph xserver/render/glyph.c:355 #2 in ProcRenderAddGlyphs xserver/render/render.c:1085 #3 in Dispatch xserver/dix/dispatch.c:546 #4 in dix_main xserver/dix/main.c:271 #5 in main xserver/dix/stubmain.c:34 #6 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-use-after-free xserver/render/glyph.c:252 in FreeGlyph To avoid that, make sure not to free the given glyph in AddGlyph(). v2: Simplify the test using the boolean returned from AddGlyph() (Michel) v3: Simplify even more by not freeing the glyph in AddGlyph() (Peter) Fixes: bdca6c3d - render: fix refcounting of glyphs during ProcRenderAddGlyphs Closes: xorg/xserver#1659 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Part-of: <xorg/xserver!1476>
-
Not used anywhere, also not in drivers, so we can drop it. Probably never been used, just added accidentially back in 2008. Fixes: 68bd7ac1 Signed-off-by:
Enrico Weigelt, metux IT consult <info@metux.net> Part-of: <!1477>
-
xkbstr.h uses types from Xdefs.h (eg. Bool) but doesn't include it. If somebody includes it, w/o including Xdefs.h first, compile breaks: ../include/xkbstr.h:84:5: error: unknown type name ‘Bool’ 84 | Bool active; | ^~~~ ../include/xkbstr.h:517:5: error: unknown type name ‘Bool’ 517 | Bool num_groups_changed; | ^~~~ ../include/xkbstr.h:608:5: error: unknown type name ‘Bool’ 608 | Bool has_own_state; | ^~~~ Signed-off-by:
Enrico Weigelt, metux IT consult <info@metux.net> Part-of: <xorg/xserver!1474>
-
This tests override WriteToClient() with their own custom function to check for validity. Unfortunately they also papered over bugs - to compare values we had to swap back thus modifying the original reply. This doesn't really have an effect on most reply handling but for those with extra data it may affect how they are processed. Fix this by copying the reply so any of the fields within that we swap is left as-is and put some basic sanity checks in for the length we pass in. Part-of: <!1469>
-
This function was (accidentally ?) added back in 2008, but never used. Fixes: 68bd7ac1 Signed-off-by:
Enrico Weigelt, metux IT consult <info@metux.net> Part-of: <xorg/xserver!1472>
-
When a present request is received, Xwayland will check if there is an existing request targeting the same window and msc and scrap the older request if so. Alas, this does not interact well the older fence-based or newer syncobj-based synchronization features of the Present extension. Since execution of a request may be delayed for an unknown length of time while waiting for a fence to be signaled, the target msc computed upon receiving a request may not match the actual msc at which the request is executed. Therefore, we cannot determine in advance whether a more recently received request will make an older request redundant. This change removes the code to scrap pending present requests. We must also ensure requests are executed in the correct order even if their fences are signaled out of order. To achieve this, whenever execution of a request needs to wait for a fence, execution of any later-received requests will be blocked until the earlier request is ready. The blocked requests will be added to a list tracked in the xwl_present_window struct. Once the earlier request's fence is signaled, any blocked requests will be re-executed. Signed-off-by:
Erik Kurzinger <ekurzinger@nvidia.com> Part-of: <xorg/xserver!967>
-
This protocol allows for explicit synchronization of GPU operations by Wayland clients and the compositor. Xwayland can make use of this to ensure any rendering it initiates has completed before the target image is accessed by the compositor, without having to rely on kernel-level implicit synchronization. Furthermore, for X11 clients that also support explicit synchronization using the mechanisms exposed in the DRI3 and Present extensions, this Wayland protocol allows us to simply forward the timeline, acquire, and release points directly to the compositor, ideally avoiding any premature stalls in the presentation pipeline. Signed-off-by:
Erik Kurzinger <ekurzinger@nvidia.com> Part-of: <xorg/xserver!967>
-