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 21916ae148)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1494>
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 49b8f131f7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1494>
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 d36f66f15d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1494>
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 0408fcb329)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: aa05f38f3 - xwayland: Add SourceValidate hook
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1485>
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: 6f0b9deed6 ("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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: 6f0b9deed6 ("xwayland: use drmDevice to compare DRM devices")
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1484>
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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/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: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Together, DRI3 1.4 and Present 1.4 allow clients to explicitly
synchronize GPU rendering with presentation using DRM syncobjs. Here we
add the necessary support to Xwayland's glamor and Present
infrastructure to enable this functionality.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
If a presentation request is delayed while waiting for a fence, the
original target msc may no longer be correct. Instead, we should compute
a new target msc in xwl_present_re_execute.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Without either implicit or explicit synchronization, the result of rendering is
pretty much undefined, and many glitches can appear. This still doesn't synchronize
buffer release, but it works around most glitches until explicit sync is supported.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Implement fractional scale with Xwayland rootful by scaling the content
to the desired fractional scale using a viewport.
For now this applies to Xwayland rootful only.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Fractional scaling may not be available, or not suitable for the current
configuration (e.g. if running rootless).
Add a helper function to tell whether fractional scaling should be used.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
