This allows e.g.
xfwm4 --vblank=xpresent
to hit the page flip path instead of copies.
In the future, Mesa might also use the Present extension with software
rendering.
This can happen if the window has never completed a Present operation.
Fixes: 4230176080 ("xwayland/present: Embed present_vblank_rec in xwl_present_event")
This will be needed with the next commit: If a child window completely
obscures a toplevel ancestor of different depth, the child window can
use page flipping only if the depth of the presented pixmap matches that
of the window's backing pixmap, or the former may contain pixel values
which are not suitable for the toplevel window's depth.
Nothing should be relying on this anymore, so use a counter like other
places in the tree instead. This ensures that the event_id doesn't get
cast back into a pointer again in future, and also may be slightly less
confusing in cases where calloc reuses an address as debug logs would
show the same event_id for those but now they will be distinct.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
On traditional 32-bit and 64-bit architectures, uint64_t can be abused
to hold a uintptr_t and be cast back to a valid pointer. However, on
CHERI, and thus Arm's Morello prototype, pointers are capabilities,
which contain a traditional address alongside additional metadata,
including a tag bit that ensures it cannot be forged (the only way to
get a capability with the tag bit set is by using instructions that take
in another valid capability with sufficient bounds/permissions/etc for
the request, and any other operation, like overwriting individual bytes
in memory, will give a capability whose tag is clear). Casting a pointer
to a uintptr_t is fine as uintptr_t is represented as a capability, but
casting to a uint64_t yields just the address, losing the metadata and
tag. Thus, when cast back to a uintptr_t, the capability remains invalid
and faults on any attempt to dereference.
As with various other places in the tree, address this by searching for
the pointer in a list so that we no longer rely on this undefined
behaviour.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
All these arguments other than damage come from the vblank itself so
passing the vblank simplifies the caller. Moreover, we pass the event_id
solely so we can get back to the event, which is just the (extended)
vblank, so passing the vblank avoids that round trip.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
By adding a new xwl_present_event_from_vblank function we can avoid
turning the vblank into an event_id, and also abstract away the exact
encoding for event_id from most places.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
It could happen with the following call path:
frame_callback
xwl_present_frame_callback
xwl_present_msc_bump
xwl_present_execute
xwl_present_flip
xwl_window_create_frame_callback
The nested loop called xwl_present_reset_timer, which may end up calling
xorg_list_del for the entry after the one frame_callback started the
chain for. This resulted in the outer loop never terminating, because
its next element wasn't hooked up to the list anymore.
We avoid this by calling xwl_present_reset_timer as needed in
frame_callback, and bailing from xwl_window_create_frame_callback if it
was called from the former.
We also catch nested calls and FatalError if they ever happen again due
to another bug.
v2:
* Leave xwl_present_reset_timer call in xwl_present_frame_callback,
needed if xwl_present_msc_bump didn't hook up the window to the frame
callback list again.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442
If the dmabuf protocol's feedback object gave us a new list of
modifiers, send PresentCompleteModeSuboptimalCopy to the client
to inform them that they need to call GetSupportedModifiers.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Even if there's no pending frame callback yet.
Without this, if there was no pending frame callback yet in
xwl_present_queue_vblank, xwl_present_msc_bump would only get called
from xwl_present_timer_callback, resulting in the MSC ticking at ~58
Hertz.
Doing this requires some adjustments elsewhere:
1. xwl_present_reset_timer needs to check for a pending frame callback
as well.
2. xwl_window_create_frame_callback needs to call
xwl_present_reset_timer for all child windows hooked up to
frame_callback_list, to make sure the timer length takes the pending
frame callback into account.
3. xwl_present_flip needs to hook up the window to frame_callback_list
before calling xwl_window_create_frame_callback, for 2. to work.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1309
Fixes: 9b31358c52 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Without this, xwl_present_reset_timer would call
xwl_present_timer_callback if the timer was originally armed over a
second ago. xwl_present_timer_callback would call xwl_present_msc_bump,
which could end up hooking up the window to
xwl_window->frame_callback_list again. This would lead to use-after-free
in xwl_present_cleanup:
Invalid write of size 8
at 0x42B65C: __xorg_list_del (list.h:183)
by 0x42B693: xorg_list_del (list.h:204)
by 0x42C041: xwl_present_cleanup (xwayland-present.c:354)
by 0x423669: xwl_destroy_window (xwayland-window.c:770)
by 0x4FDDC5: compDestroyWindow (compwindow.c:620)
by 0x5233FB: damageDestroyWindow (damage.c:1590)
by 0x501C5F: DbeDestroyWindow (dbe.c:1326)
by 0x4EF35B: FreeWindowResources (window.c:1018)
by 0x4EF687: DeleteWindow (window.c:1086)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
Address 0x12f44980 is 144 bytes inside a block of size 160 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x423115: xwl_unrealize_window (xwayland-window.c:621)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
by 0x4F424B: UnmapWindow (window.c:2863)
by 0x4EF58C: DeleteWindow (window.c:1075)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
by 0x5E27EE: ClientReady (connection.c:599)
by 0x5E6CB7: ospoll_wait (ospoll.c:657)
by 0x5DE6CD: WaitForSomething (WaitFor.c:208)
Block was alloc'd at
at 0x4849464: calloc (vg_replace_malloc.c:1328)
by 0x4229CE: ensure_surface_for_window (xwayland-window.c:439)
by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
by 0x4EDB3F: TraverseTree (window.c:441)
by 0x4FC851: compSetPixmap (compwindow.c:151)
by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
by 0x4FC938: compCheckRedirect (compwindow.c:174)
by 0x4FCD1D: compRealizeWindow (compwindow.c:274)
by 0x4F36EC: RealizeTree (window.c:2606)
by 0x4F39F5: MapWindow (window.c:2683)
Fixes: 288ec0e046 ("xwayland/present: Run fallback timer callback after more than a second")
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
If the Wayland compositor doesn't send a pending frame event, e.g.
because the Wayland surface isn't visible anywhere, it could happen that
the timer kept getting pushed back and never fired. This resulted in an
enormous list of pending vblank events, which could take minutes to
process when the frame event finally arrived.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1110
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Jaap Buurman <jaapbuurman@gmail.com>
xwl_present_reset_timer checks if the pending flip is synchronous, so
we need to call it after adding the pending flip to the flip queue.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1219
Fixes: b2a06e0700 "xwayland/present: Drop sync_flip member of struct xwl_present_window"
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
We are handling two cases here: the active flip or the pending flip.
For the pending flip (event->pending == TRUE), we called
xwl_present_release_pixmap.
For the active flip (event->pending == FALSE), we called
xwl_present_release_event. However, xwl_present_flip_notify_vblank
already unhooked event->vblank.event_queue. So this was effectively the
same as calling xwl_present_release_pixmap.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Use present_vblank_rec::event_queue instead.
The changes in xwl_present_execute shouldn't really be needed, since
we should never hit queue_vblank in present_execute_wait. But let's be
safe rather than sorry, plus this simplifies the code.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Can just call xwl_present_execute directly.
This allows dropping the window member from struct xwl_present_window as
well.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
We clear the vblank->pixmap field, so next time xwl_present_execute
falls through to present_execute_post.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This allows for various simplifications.
Use the pointer to the struct memory as the event ID. In contrast to
the SCMD code for Xorg (where pending DRM events cannot be cancelled),
this is safe here, because we can destroy pending Wayland callbacks. So
we can't get a callback with a stale pointer to freed memory.
Remove xwl_present_window::release_list in favour of
present_vblank_rec::window_list.
Remove xwl_present_event::xwl_present_window in favour of
present_vblank_rec::window.
xwl_present_free_event is never called for a NULL pointer anymore, no
need to check.
v2:
* Restore DestroyWindow wrapping order to make sure
present_destroy_window doesn't call xwl_present_abort_vblank.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
We can call xwl_present_free_event unconditionally from
xwl_present_abort_vblank, since the sync_callback is already destroyed
in xwl_present_cleanup.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Mainly into xwl_present_check_flip, and call that from
present_wnmd_check_flip_window.
No need for them to be separate anymore.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This will allow eliminating indirections and making the Xwayland Present
code more efficient and easier to follow.
While this technically changes the Xorg video driver ABI, I don't know
of any drivers using the dropped present_wnmd_* symbols, and I doubt a
Xorg driver could make use of them as is anyway.
(As a bonus, Xorg no longer links any Xwayland specific Present code)
v2:
* Wrap DestroyWindow before initializing Present, so that
present_destroy_window runs before xwl_present_cleanup. Avoids crash
due to present_destroy_window calling xwl_present_* functions when
xwl_present_window was already freed. (Olivier Fourdan)
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Allow X11 clients to create shared pixmaps via the MIT-SHM
extension under Xwayland. Tested with a wlroots patch [1].
Also add a few assertions to make sure we have wl_buffers where we
need them.
[1]: https://github.com/swaywm/wlroots/pull/2875
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
If the buffer is NULL, do not even try to attach it, and risk a Wayland
protocol error which would be fatal to us.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Provides an implementation for the pixmap_from_buffers DRI3 function for
xwayland's eglstream backend. This will be used by the NVIDIA GLX driver
to pass buffers from client applications to the server. These can then
be presented using the PRESENT extension.
To hopefully make this less error-prone, we also introduce a "type"
field for this struct to distinguish between xwl_pixmaps for the new
DRI3-created pixmaps and those for the existing glamor-created pixmaps.
Additionally, the patch enables wnmd present mode with the eglstream backend.
This involves creating a wl_buffer for the provided dma-buf before importing it
into EGL and passing this to the compositor so it can be scanned out directly
if possible.
Since both backends now support this present mode, the HAS_PRESENT_FLIP flag is
no longer needed, so it can be removed.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Michel Dänzer
Xaver Hugl
Jessica Clarke
Austin Shafer
Simon Ser
Olivier Fourdan
Erik Kurzinger