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 now fixed in egl-wayland 1.1.7, we can safely drop all
that logic from Xwayland EGLstream backend.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1189
If the pixmap does not actually change in set_window_pixmap(), there is
no need to invalidate the pending stream, if there's one.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
In xwl_glamor_eglstream_get_wl_buffer_for_pixmap. This can likely be hit
now with an SHM pixmap via the Present flip path. There might be other
corner cases.
Fixes: f3eb1684fa "xwayland: enable MIT-SHM shared pixmaps"
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
That will dramatically affect performance, might as well log when we
cannot use GL_OES_EGL_image with the NVIDIA closed-source driver.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
If the EGLStream backend is able to use hardware acceleration with the
NVIDIA closed source driver, we should use the "nvidia" GLX
implementation instead of the one from Mesa to take advantage of the
NVIDIA hardware accelerated rendering.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When eglSwapBuffers inserts a new frame into a window's stream, there may be a
delay before the state of the consumer end of the stream is updated to reflect
this. If the subsequent wl_surface_attach, wl_surface_damage, wl_surface_commit
calls are received by the compositor before then, it will (typically) re-use
the previous frame acquired from the stream instead of the latest one.
This can leave the window displaying out-of-date contents, which might never be
updated thereafter.
To fix this, after calling eglSwapBuffers, xwl_glamor_eglstream_post_damage
should call eglStreamFlushNV. This call will block until it can be guaranteed
that the state of the consumer end of the stream has been updated to reflect
that a new frame is available.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1171
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
As of commit 098e0f52 xwl_glamor_eglstream_allow_commits will not allow commits
if the xwl_pixmap does not have an EGLSurface. This is valid for pixmaps backed
by an EGLStream, however pixmaps backed by a dma-buf for OpenGL or Vulkan
rendering will never have an EGLSurface. Unlike EGLStream backed pixmaps,
though, glamor will render directly to the buffer that Xwayland passes to the
compositor. Hence, they don't require the intermediate copy in
xwl_glamor_eglstream_post_damage that EGLStream backed pixmaps do, so there is
no need for an EGLSurface.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The EGLstream backend's post damage function uses a shader and
glDrawArrays() to copy the data from the glamor's pixmap texture prior
to do the eglSwapBuffers().
However, glDrawArrays() can be affected by the GL state, and therefore
not reliably produce the expected copy, causing the content of the
buffer to be corrupted.
Make sure to set the ALU to GXCopy prior to call glDrawArrays() to get
the expected result.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, the EGLstream backend would increment the pixmap refcount for
each commit, and decrease that refcount on the wl_buffer release
callback.
But that's relying on the compositor sending us a release callback for
each commit, otherwise the pixmap refcount will keep increasing and the
pixmap will be leaked.
So instead, increment the refcount on the pixmap only when we have not
received a release notification for the wl_buffer, to avoid increasing
the pixmap refcount more than once without a corresponding release
event.
This way, if the pixmap is still in use when released on the X11 side,
the EGL stream will be kept until the compositor releases it.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
EGLstream's post_damage() would unconditionally return success
regardless of the actual status of the eglSwapBuffers().
Yet, if eglSwapBuffers() fails, we should not post the corresponding
damage as they wouldn't match the actual content of the buffer.
Use the eglSwapBuffers() return value as the return value for
post_damage() and do not take a refrence on the pixmap if it fails.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Use calloc() instead of malloc() like the rest of the code.
Also fix the arguments of calloc() calls to match the definition which
is calloc(size_t nmemb, size_t size).
This is a cleanup patch, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The EGL surface for the xwl_pixmap is created once the stream is ready
and valid.
If the pixmap's EGL surface fails, for whatever reason, the xwl_pixmap
will be unusable and will end up as an invalid wl_buffer.
Make sure we do not allow commits in that case and recreate the
xwl_pixmap/stream.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Now that the pending stream is associated with the xwl_pixmap for
EGLStream and the xwl_pixmap itself is associated to the pixmap, we have
a reliable way to get to those data from any pending stream.
As a result, the list of pending streams that we keep in the EGLStream
global structure becomes useless.
So we can drop the pending stream's xwl_pixmap and also the list of
pending streams altogether, and save us a walk though that list for each
callback.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Commit affc47452 - "xwayland: Drop the separate refcount for the
xwl_pixmap" removed the separate reference counter for the xwl_pixmap
which holds the EGLStream.
While that works fine for the common case, if the window's pixmap is
changed before the stream is ready, the older pixmap will be destroyed
and the xwl_pixmap along with it, even if the compositor is still using
the stream.
The code that was removed with commit affc47452 was taking care of that
by increasing the separate reference counter for the xwl_pixmap, but it
no longer the case.
As a result, we may end up with the EGL stream in the wrong state when
trying to use it, which will cascade down into all sort of issues.
To avoid the problem, increase the reference count on the pixmap when it
is marked as invalid in EGLStream's SetWindowPixmap().
This way, the xwl_pixmap and the EGLStream are kept until released by
the compositor, even when the pixmap changes before stream is ready.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: affc47452 xwayland: Drop the separate refcount for the xwl_pixmap
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Previously, we would have pending streams associated with top level X11
windows, keeping temporary accounting for the pending streams before
they get fully initialized for the xwl_pixmap which would be associated
with X11 pixmaps.
If the window content changes before the stream is ready, the
corresponding pending stream would be marked as invalid and the pending
stream would be eventually removed once the stream becomes ready.
Since commit affc47452 - "xwayland: Drop the separate refcount for the
xwl_pixmap", we no longer keep a separate reference counter for the
xwl_pixmap, but rather tie it to the X11 pixmap lifespan. Yet, the
pending stream would still be associated with the X11 toplevel window.
Dissociate the pending streams from the X11 toplevel window, to keep it
tied only to the xwl_pixmap so that we can have:
- pixmap <-> xwl_pixmap
- xwl_pixmap <-> pending stream
Of course, the pending streams remain temporary and get removed as soon
as the ready callback is triggered, but the pending streams are not
linked to the X11 window anymore which can change their content, and
therefore their X11 pixmap at any time.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
eglCreateStreamKHR() can fail and return EGL_NO_STREAM_KHR, in which
case there is no point in trying to create a buffer from it.
Similarly, eglCreateStreamProducerSurfaceKHR() also fail and return
EGL_NO_SURFACE, which in turn will be used in eglMakeCurrent() as
draw/read surface, and therefore would mean no draw/read buffer.
In those cases, log the error, and bail out early. That won't solve the
issue but will help with investigating the root cause of issues with
EGLStream backend.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Some functions are called "callback" whereas they are not longer
callback functions or "unref" while they no longer deal with a reference
counter anymore, which is quite confusing. Rename those functions to be
more explicit.
Also, the pending streams can be destroyed in different places, move the
common code to separate function to avoid duplicating code and help with
readability of the code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
The EGLStream backend would sometime generate GL errors trying to draw
to the framebuffer, which gives an invalid buffer, which in turn would
generate a Wayland error from the compositor which is fatal to the
client.
Check the framebuffer status and bail out early if it's not complete,
to avoid getting into trouble later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
If the glamor backend failed to post damage, the caller should do the
same to avoid a failure to attach the buffer to the Wayland surface.
Change the API of Xwayland's glamor backend post_damage() to return a
status so that xwl_window_post_damage() can tell whether the callee
failed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
EGLStream wl_eglstream_display_create_stream() may fail, yet Xwayland
would try to attach the buffer which may cause a fatal Wayland protocol
error raised by the compositor.
Check if the buffer creation worked, and fail gracefully otherwise (like
wayland-eglsurface does).
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
If a window is being used for direct rendering with OpenGL or Vulkan, and is
using the flipping path for presentation, it's pixmap will be set to a dma-buf
backed pixmap created by the client-side GL driver. However, this means that
xwl_glamor_eglstream_post_damage won't work since it requires that the pixmap
has an EGLSurface that it can render to, which dma-buf backed pixmaps do not.
In this case, though, xwl_glamor_eglstream_post_damage is not necessary since
glamor will have rendered directly to the pixmap, so we can simply pass it
directly to the compositor. There's no need for the intermediate copy we
normally do in that function.
Therefore, this change adds an early-return case to post_damage for dma-buf
backed pixmaps, and removes the corresponding asserts from that function and
allow_commits.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
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>
This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.
This exposes a new glamor backend function, check_flip, which can be
used to control whether flipping is supported for the given pixmap.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
There are currently no callers that make use of the "created" output parameter
of xwl_glamor_pixmap_get_wl_buffer. Remove it, along with the corresponding
argument of the associated EGL backend entrypoint.
EGLStream implementation in Xwayland keeps a list of pending streams for
a window.
If the windows's pixmap is destroyed while there is a pending stream,
the pending stream will point to freed memory once the callback is
triggered.
Make sure to cancel the pending stream if there's one when the pixmap is
destroyed.
v2:
* Use xorg_list_for_each_entry() instead of the safe variant (Michel
Dänzer <mdaenzer@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1096
Commit 77658741 - "xwayland: Add buffer release callback" added an API
to deal with Wayland buffer release callbacks.
The EGLstream implementation has its own wl_buffer callback, move that
to the buffer release API instead so we don't have to deal with Wayland
buffers directly and match the other Xwayland pixmap backend
implementations.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Erik Kurzinger <ekurzinger@nvidia.com>
Instead, bump the pixmap's refcount at the bottom of post_damage to
reflect the compositor's hold on the buffer, and "destroy" the pixmap in
the buffer release callback (which will dec the pixmap's refcount and
free if necessary).
Signed-off-by: Adam Jackson <ajax@redhat.com>
The EGLStream backend keeps a queue of pending streams for each Xwayland
window.
However, when this pending queue is freed, the corresponding private
data may not be cleared (typically if the pixmap for this window has
changed before the compositor finished attaching the consumer for the
window's pixmap's original eglstream), leading to a use-after-free and a
crash when trying to use that data as the window pixmap.
Make sure to clear the private data when the pending stream is freed.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1055
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The present flip does not work with the EGLStream backend. Similarly,
the EGLStream backend does not require the buffer to be flushed as
eglSwapBuffers() should take care of this.
Instead of actually checking the backend in use in the present code,
add a flag in the form of a bitfield to the EGL backend to indicate
its features and requirements.
This should not introduce any functional change.
v2: Fix logical test (Adam Jackson <ajax@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Fixes build failure.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/954
Fixes: 89e32d00f6 "xwayland: Move Xwayland windows to its own sources"
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Now that each source and header should be in order, we can safely cleaup
the last remaining bits from the main `xwayland.h` which is not needed
anymore and can be removed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland screen related code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland generic pixmap code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the GLAMOR relevant declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The API `wl_buffer_add_listener` is misleading in the sense that there
can be only one `wl_buffer` release callback, and trying to add a new
listener when once is already in place will lead to a protocol error.
The Xwayland EGL backends may need to set up their own `wl_buffer`
release listener, meaning that there is no way to our own `wl_buffer`
release callback.
To avoid the problem, add our own callback API to be notified when the
`wl_buffer` associated with an `xwl_pixmap` is released, triggered from
the different `xwl_pixmap` implementations.
Also update the Present code to use the new buffer release callback API.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The definition by the manual is `calloc(size_t nmemb, size_t size)`.
Swap the arguments of calloc() calls to match the definition.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS,
EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers
shipped with libglvnd.
This fixes the xserver not building with the libglvnd-1.2.0 headers:
In file included from /usr/include/EGL/eglplatform.h:128,
from /usr/include/epoxy/egl_generated.h:11,
from /usr/include/epoxy/egl.h:46,
from glamor_priv.h:43,
from glamor_composite_glyphs.c:25:
/usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC'
222 | *GC;
| ^~
In file included from glamor.h:34,
from glamor_priv.h:32,
from glamor_composite_glyphs.c:25:
../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here
282 | } GC;
| ^~
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When retrieving the Wayland buffer from a pixmap, if the buffer already
exists, the GBM backend will return that existing buffer.
However, as seen with the Present issues, if the call had previously
passed a wrong size, that buffer will remain at the wrong size for as
long as the buffer exists, which is error prone.
Considering that the width/height passed to get_wl_buffer() is always the
actual pixmap drawable size, and considering that the EGLStream backend
makes no use of the size either, there is really no point in passing the
width/height around.
Simplify the xwl_glamor_pixmap_get_wl_buffer() and EGL backends API by
removing the pixmap size, and use the drawable size instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority"
extension, make sure it's actually available before using it.
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
To be able to check for availability of the Wayland interfaces required
to run a given EGL backend (either GBM or EGLStream for now), we need
to have each backend structures and vfuncs in place before we enter the
Wayland registry dance.
That basically means that we should init all backends at first, connect
to the Wayland compositor and query the available interfaces and then
decide which backend is available and should be used (or none if either
the Wayland interfaces or the EGL extensions are not available).
For this purpose, hold an egl_backend struct for each backend we are to
consider prior to connect to the Wayland display so that, when we get to
query the Wayland interfaces, everything is in place for each backend to
handle the various Wayland interfaces.
Eventually, when we need to chose which EGL backend to use for glamor,
the available Wayland interfaces and EGL extensions available are all
known to Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Introduces a new egl_backend function to let the EGL backend check for
the presence of the required Wayland interfaces.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Both xwl_glamor_init_wl_registry() and the Wayland global registry
handler use the interface id/name in that order, using name/id in the
egl_backend vfunc makes things confusing and error prone.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Functions such as:
xwl_glamor_egl_supports_device_probing()
xwl_glamor_egl_get_devices()
xwl_glamor_egl_device_has_egl_extensions()
Are of no use outside of EGLStream support, move them to the relevant
source file.
Similarly, the other glamor functions such as:
xwl_glamor_init()
xwl_screen_set_drm_interface()
xwl_screen_set_dmabuf_interface()
xwl_glamor_pixmap_get_wl_buffer()
xwl_glamor_init_wl_registry()
xwl_glamor_post_damage()
xwl_glamor_allow_commits()
xwl_glamor_egl_make_current()
Are useless without glamor support enabled, move those within a
a "#ifdef XWL_HAS_GLAMOR" in xwayland.h
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
