xserver merge requestshttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests2021-06-14T09:31:38Zhttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/674xwayland/eglstream: Handle xwl_pixmap_get returning NULL2021-06-14T09:31:38ZMichel Dänzerxwayland/eglstream: Handle xwl_pixmap_get returning NULLPlus some cleanups.Plus some cleanups.https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/675xwayland/present: Move DIX Present WNMD code to Xwayland DDX2021-09-16T14:12:26ZMichel Dänzerxwayland/present: Move DIX Present WNMD code to Xwayland DDXThe WNMD abstraction serves no purpose for Xwayland alone. No other users have emerged in the 3 years it's been there, and I'm not aware of any plans for other users.
So, this MR abolishes the abstraction and moves the WNMD specific cod...The WNMD abstraction serves no purpose for Xwayland alone. No other users have emerged in the 3 years it's been there, and I'm not aware of any plans for other users.
So, this MR abolishes the abstraction and moves the WNMD specific code to the Xwayland DDX. This then opens up various simplifications and cleanups, which will make it easier to extend and improve Xwayland's Present support.
`struct xwl_present_event` now embeds `present_vblank_rec`, and all but one of its other members are eliminated. The remaining `pixmap` member could be eliminated as well, but it's a bit more complicated. And I suspect more members might be added for other purposes in the near future, e.g. for `presentation-time` protocol support. If that turns out not to be the case, I can remove it in a later MR.
**Testing performed**
For all 4 cases (flip and non-flip paths, each with or without sync-to-vblank):
* Verified correct operation with `glxgears`.
* Same with `Xwayland` running in `valgrind`, no leaks or other errors reported.
* Same with an additional debugging patch to confirm there's no build-up of lingering `struct xwl_present_event`s which are only cleaned up when the window is destroyed.https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/698eglstream: Remove stream validity2021-06-30T07:27:21ZOlivier Fourdaneglstream: Remove stream validityTo avoid an EGL stream in the wrong state, if the window pixmap changed
before the stream was connected, we would still keep the pending stream
but mark it as invalid. Once the callback is received, the pending would
be simply discarded....To avoid an EGL stream in the wrong state, if the window pixmap changed
before the stream was connected, we would still keep the pending stream
but mark it as invalid. Once the callback is received, the pending would
be simply discarded.
But all of this is actually to avoid a bug in egl-wayland, there should
not be any problem with Xwayland destroying an EGL stream while the
compositor is still using it.
With that bug fixes in egl-wayland, we can now safely drop all that
logic from Xwayland EGLstream backend.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1189https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/755xwayland/present: Move xwl_present_reset_timer call out of xwl_present_flip2021-09-20T10:20:15ZMichel Dänzerxwayland/present: Move xwl_present_reset_timer call out of xwl_present_flipxwl_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.
Fixes: b2a06e0700fa "xwayland/present: Drop sync_flip member of struct xwl_present_window"
Closes:...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.
Fixes: b2a06e0700fa "xwayland/present: Drop sync_flip member of struct xwl_present_window"
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1219https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/834xwayland/present: Run fallback timer callback after more than a second2022-01-10T09:30:51ZMichel Dänzerxwayland/present: Run fallback timer callback after more than a secondIf 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 ...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/1110xwayland-22.1.0https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/847Fixed building when --disable-present option is used2022-01-27T10:19:07ZHans MüllerFixed building when --disable-present option is usedSince a few years (since 09230a2d), the X server wasn't compileable when
--disable-present was passed to the autogen script.
This commit aims to fix this by adding directives and conditions
around some code introduced in 09230a2d, cef12e...Since a few years (since 09230a2d), the X server wasn't compileable when
--disable-present was passed to the autogen script.
This commit aims to fix this by adding directives and conditions
around some code introduced in 09230a2d, cef12efc and 16571b89.
Signed-off-by: Hans Müller <schreibemirhalt@gmail.com>https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/880xwayland/present: Fix a couple of use-after-free2022-03-15T09:05:37ZOlivier Fourdanxwayland/present: Fix a couple of use-after-freeFixes a couple of use-after free found when looking into #1324
Marking as draft as unsure if those are actually valid wrt. present.
/cc @daenzerFixes a couple of use-after free found when looking into #1324
Marking as draft as unsure if those are actually valid wrt. present.
/cc @daenzerhttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/884xwayland: Always hook up frame_callback_list in xwl_present_queue_vblank2022-03-24T08:57:40ZMichel Dänzerxwayland: Always hook up frame_callback_list in xwl_present_queue_vblankEven 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 tickin...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/1309https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/885[Backport to Xwayland-22.1] xwayland: Always hook up frame_callback_list in x...2022-03-25T07:43:02ZOlivier Fourdan[Backport to Xwayland-22.1] xwayland: Always hook up frame_callback_list in xwl_present_queue_vblankEven 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 tickin...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: 9b31358c52e9 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 9e5a3796108e2b89212fa440f80e918d24b971c8)https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/886[Backport to Xwayland 21.1] xwayland: Always hook up frame_callback_list in x...2022-07-20T15:08:42ZOlivier Fourdan[Backport to Xwayland 21.1] xwayland: Always hook up frame_callback_list in xwl_present_queue_vblankEven 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 tickin...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: 9b31358c52e9 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 9e5a3796108e2b89212fa440f80e918d24b971c8)https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/910xwayland/present: Do not send two idle notify events for flip pixmaps2022-06-21T09:45:52ZMichel Dänzerxwayland/present: Do not send two idle notify events for flip pixmapsCould happen if the buffer release event was already processed before
xwl_present_flips_stop.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1351Could happen if the buffer release event was already processed before
xwl_present_flips_stop.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1351Michel DänzerMichel Dänzerhttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967Explicit GPU Synchronization for DRI3, Present, and Xwayland2024-03-27T16:08:47ZErik Kurzingerekurzinger@nvidia.comExplicit GPU Synchronization for DRI3, Present, and XwaylandHere is our proposal for adding explicit GPU synchronization to the DRI3 and Present extensions, along with an implementation for Xwayland. While we at NVIDIA may be particularly keen to have this in place, since our driver lacks implici...Here is our proposal for adding explicit GPU synchronization to the DRI3 and Present extensions, along with an implementation for Xwayland. While we at NVIDIA may be particularly keen to have this in place, since our driver lacks implicit sync support, a general consensus seems to be forming around the idea that explicit sync is the best path forward for the Linux graphics stack. Xwayland will likely remain an important component in that stack for some time yet, and therefore I feel that this work will be of long-term benefit to the community more broadly.
The design takes inspiration from the proposed Wayland wp_linux_explicit_sync_v2 protocol [1], making use of DRM syncobjs as the main primitive. I believe this offers a few benefits. One, having both X11 and Wayland use a similar mechanism for explicit sync will simplify development for client-side drivers, and two, it will also hopefully make it fairly straight-forward for Xwayland itself to add support for the Wayland explicit sync protocol, presumably once it's more widely implemented by compositors.
I've tried to keep this initial proposal focused on getting a usable GPU synchronization primitive in place, and adding support for it to the PresentPixmap request, believing this to be the most important part of the presentation pipeline. Other use-cases for this primitive are conceivable, for instance perhaps in the Damage extension, but I feel that those are best left for later.
Any and all feedback is appreciated.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1006modesetting: add support for TearFree page flips2024-01-24T02:28:53ZSultan Alsawafmodesetting: add support for TearFree page flipsThis adds support for TearFree page flips to eliminate tearing without the
use of a compositor. It allocates two shadow buffers for each CRTC, a back
buffer and a front buffer, and uses damage tracking to minimize excessive
copying betwe...This adds support for TearFree page flips to eliminate tearing without the
use of a compositor. It allocates two shadow buffers for each CRTC, a back
buffer and a front buffer, and uses damage tracking to minimize excessive
copying between buffers and skip unnecessary flips when the screen's
contents remain unchanged. It works on transformed screens too, such as
rotated and scaled CRTCs.
When PageFlip is enabled, TearFree won't force fullscreen DRI clients to
synchronize their page flips to the vblank interval.
TearFree is disabled by default.https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1008xwayland: Support CHERI/Morello by not storing pointers in uint64_t2023-06-06T08:10:54ZJessica Clarkexwayland: Support CHERI/Morello by not storing pointers in uint64_tOn 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 a...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.
As part of this, a bunch of cleanup is done to reduce the number of places that have to convert from event_id back to event in the first place.
A more invasive change would be to pass the vblank itself through the callbacks, or have some kind of arbitrary data field in the vblank that's a pointer to whatever the present implementation wants (which could also allow xwayland to stop extending present_vblank_rec), but this is the simplest change to make it work and seems consistent with other places like the modesetting vblank sequence number handling and scmd.https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1057present: Send a PresentConfigureNotify event for destroyed windows2023-06-04T16:21:18ZAdam Jacksonajax@nwnk.netpresent: Send a PresentConfigureNotify event for destroyed windowsThis is a fix for a deadlock case, where the client ends up blocked
waiting for a Present event that will never come because the window was
destroyed.
The fix as written is a bit hacky. Clients will simply be sent this new
kind of event...This is a fix for a deadlock case, where the client ends up blocked
waiting for a Present event that will never come because the window was
destroyed.
The fix as written is a bit hacky. Clients will simply be sent this new
kind of event rather than selecting for a new `PresentDestroyNotify`, and
the values in the event run the risk of making the client do something
"illegal", 0x0 isn't a valid size for example. In practice I expect it's
fine, most clients are not expecting to survive their `GLXWindow` being
ripped out from under them, which means this simply promotes a
deadlock-on-exit to a crash-on-exit.
---
Posting this for discussion, I don't have a ton of time to follow up on this and I don't really care whether this is sent unconditionally or needs a whole new protocol bump. Frankly if I were bumping the protocol this is a pretty half-assed solution and #1428 is what I'd rather see. Regardless, someone decide and push this across the finish line please.xwayland-23.1.0https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1062modesetting: unflip before any setcrtc() calls2023-12-16T04:39:34ZVille Syrjälämodesetting: unflip before any setcrtc() callsMake sure we're not scanning out any fbs with fancy modifiers when
we try to light up new displays. This is already the case in cases
where the screen gets resized, but in cases where that doesn't happen
it might be possible for the mode...Make sure we're not scanning out any fbs with fancy modifiers when
we try to light up new displays. This is already the case in cases
where the screen gets resized, but in cases where that doesn't happen
it might be possible for the modeset(s) to fail due to watermark/etc.
constraints imposed by the fancy modifiers. We can avoid that by
making sure everything gets unflipped before the modeset.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1086xwayland: Prevent nested iteration over frame callback list2023-03-27T08:21:57ZMichel Dänzerxwayland: Prevent nested iteration over frame callback listIt 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...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.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1168xwayland/present: Handle NULL window_priv in xwl_present_cleanup2023-09-26T14:09:43ZMichel Dänzerxwayland/present: Handle NULL window_priv in xwl_present_cleanupThis can happen if the window has never completed a Present operation.
Fixes: 42301760802e ("xwayland/present: Embed present_vblank_rec in xwl_present_event")This can happen if the window has never completed a Present operation.
Fixes: 42301760802e ("xwayland/present: Embed present_vblank_rec in xwl_present_event")https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1183Present: Bump xserver Present version to 1.32023-12-27T16:01:04ZOlivier FourdanPresent: Bump xserver Present version to 1.3Now that the Xserver supports PresentOptionAsyncMayTear, the current
Present minor version that the xserver supports is 1.3.
Yet the version advertised by the Xserver is still 1.2. Bump the minor
version to 3 to reflect on the actual Pr...Now that the Xserver supports PresentOptionAsyncMayTear, the current
Present minor version that the xserver supports is 1.3.
Yet the version advertised by the Xserver is still 1.2. Bump the minor
version to 3 to reflect on the actual Present support in the Xserver.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: commit 2adc5c45 - add support for PresentOptionAsyncMayTearhttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1249xwayland: Enable Present extension support also with rootful / no glamor2024-01-22T14:17:53ZMichel Dänzerxwayland: Enable Present extension support also with rootful / no glamorBenefits with rootful:
* Fullscreen windows can hit the page flip path
* X client presentation is properly synchronized to the Wayland
compositor refresh cycle via frame events
As for with no glamor, while only few clients currently ...Benefits with rootful:
* Fullscreen windows can hit the page flip path
* X client presentation is properly synchronized to the Wayland
compositor refresh cycle via frame events
As for with no glamor, while only few clients currently use the Present extension without HW acceleration, Mesa might do so in the future.