andreacavalli
/
xserver-multidpi
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
xserver-multidpi/hw/xwayland/xwayland-glamor-eglstream.c

1151 lines
36 KiB
C
Raw Normal View History

xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
/*
* Copyright © 2017 Red Hat Inc.
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use, copy,
* modify, merge, publish, distribute, sublicense, and/or sell copies
* of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including
* the next paragraph) shall be included in all copies or substantial
* portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
* HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*
* Authors:
* Lyude Paul <lyude@redhat.com>
*
*/
xwayland: Move GLAMOR declarations to their own header 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>
2019-12-16 17:23:30 +01:00
#include <xwayland-config.h>
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
#define MESA_EGL_NO_X11_HEADERS
glamor/xwayland: Define EGL_NO_X11 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>
2019-11-04 20:03:17 +01:00
#define EGL_NO_X11
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
#include <glamor_egl.h>
#include <glamor.h>
xwayland/eglstream: Set ALU to GXCopy for blitting 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>
2021-04-30 16:23:10 +02:00
#include <glamor_priv.h>
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
#include <glamor_transform.h>
#include <glamor_transfer.h>
#include <xf86drm.h>
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
#include <dri3.h>
#include <drm_fourcc.h>
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
#include <epoxy/egl.h>
xwayland: Move GLAMOR declarations to their own header 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>
2019-12-16 17:23:30 +01:00
#include "xwayland-glamor.h"
xwayland: Separate Xwayland pixmap code 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>
2019-12-17 17:07:58 +01:00
#include "xwayland-pixmap.h"
xwayland: Separate Xwayland screen code 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>
2019-12-18 10:03:43 +01:00
#include "xwayland-screen.h"
xwayland: Include xwayland-window.h from xwayland-glamor-eglstream.c Fixes build failure. Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/954 Fixes: 89e32d00f6e0 "xwayland: Move Xwayland windows to its own sources" Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
2019-12-23 09:26:17 +01:00
#include "xwayland-window.h"
xwayland: Move GLAMOR declarations to their own header 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>
2019-12-16 17:23:30 +01:00
#include "wayland-eglstream-client-protocol.h"
#include "wayland-eglstream-controller-client-protocol.h"
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
#include "linux-dmabuf-unstable-v1-client-protocol.h"
xwayland: Move GLAMOR declarations to their own header 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>
2019-12-16 17:23:30 +01:00
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
struct xwl_eglstream_private {
EGLDeviceEXT egl_device;
struct wl_eglstream_display *display;
struct wl_eglstream_controller *controller;
uint32_t display_caps;
EGLConfig config;
Bool have_egl_damage;
xwayland/eglstream: flush stream after eglSwapBuffers 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>
2021-05-11 23:00:21 +02:00
Bool have_egl_stream_flush;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
GLint blit_prog;
GLuint blit_vao;
GLuint blit_vbo;
GLuint blit_is_rgba_pos;
};
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
enum xwl_pixmap_type {
XWL_PIXMAP_EGLSTREAM, /* Pixmaps created by glamor. */
XWL_PIXMAP_DMA_BUF, /* Pixmaps allocated through DRI3. */
};
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
struct xwl_pixmap {
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
enum xwl_pixmap_type type;
/* add any new <= 4-byte member here to avoid holes on 64-bit */
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
struct xwl_screen *xwl_screen;
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
struct wl_buffer *buffer;
xwayland/eglstream: Remove stream validity 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
2021-04-30 09:56:05 +02:00
struct wl_callback *pending_cb;
xwayland/eglstream: Do not always increment pixmap refcnt on commit 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>
2021-05-04 10:56:38 +02:00
Bool wait_for_buffer_release;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
/* XWL_PIXMAP_EGLSTREAM. */
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
EGLStreamKHR stream;
EGLSurface surface;
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
/* XWL_PIXMAP_DMA_BUF. */
EGLImage image;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
};
static DevPrivateKeyRec xwl_eglstream_private_key;
static inline struct xwl_eglstream_private *
xwl_eglstream_get(struct xwl_screen *xwl_screen)
{
return dixLookupPrivate(&xwl_screen->screen->devPrivates,
&xwl_eglstream_private_key);
}
static GLint
xwl_eglstream_compile_glsl_prog(GLenum type, const char *source)
{
GLint ok;
GLint prog;
prog = glCreateShader(type);
glShaderSource(prog, 1, (const GLchar **) &source, NULL);
glCompileShader(prog);
glGetShaderiv(prog, GL_COMPILE_STATUS, &ok);
if (!ok) {
GLchar *info;
GLint size;
glGetShaderiv(prog, GL_INFO_LOG_LENGTH, &size);
info = malloc(size);
if (info) {
glGetShaderInfoLog(prog, size, NULL, info);
ErrorF("Failed to compile %s: %s\n",
type == GL_FRAGMENT_SHADER ? "FS" : "VS", info);
ErrorF("Program source:\n%s", source);
free(info);
}
else
ErrorF("Failed to get shader compilation info.\n");
FatalError("GLSL compile failure\n");
}
return prog;
}
static GLuint
xwl_eglstream_build_glsl_prog(GLuint vs, GLuint fs)
{
GLint ok;
GLuint prog;
prog = glCreateProgram();
glAttachShader(prog, vs);
glAttachShader(prog, fs);
glLinkProgram(prog);
glGetProgramiv(prog, GL_LINK_STATUS, &ok);
if (!ok) {
GLchar *info;
GLint size;
glGetProgramiv(prog, GL_INFO_LOG_LENGTH, &size);
info = malloc(size);
glGetProgramInfoLog(prog, size, NULL, info);
ErrorF("Failed to link: %s\n", info);
FatalError("GLSL link failure\n");
}
return prog;
}
static void
xwl_eglstream_cleanup(struct xwl_screen *xwl_screen)
{
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
if (xwl_eglstream->display)
wl_eglstream_display_destroy(xwl_eglstream->display);
if (xwl_eglstream->controller)
wl_eglstream_controller_destroy(xwl_eglstream->controller);
if (xwl_eglstream->blit_prog) {
glDeleteProgram(xwl_eglstream->blit_prog);
glDeleteBuffers(1, &xwl_eglstream->blit_vbo);
}
free(xwl_eglstream);
}
xwayland: move glamor specific routines 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>
2018-06-05 19:38:36 +02:00
static Bool
xwl_glamor_egl_supports_device_probing(void)
{
return epoxy_has_egl_extension(NULL, "EGL_EXT_device_base");
}
static void **
xwl_glamor_egl_get_devices(int *num_devices)
{
xwayland: fix a realloc OOM error case Found by coverity Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2018-10-16 02:37:16 +02:00
EGLDeviceEXT *devices, *tmp;
xwayland: move glamor specific routines 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>
2018-06-05 19:38:36 +02:00
Bool ret;
int drm_dev_count = 0;
int i;
if (!xwl_glamor_egl_supports_device_probing())
return NULL;
/* Get the number of devices */
ret = eglQueryDevicesEXT(0, NULL, num_devices);
if (!ret || *num_devices < 1)
return NULL;
devices = calloc(*num_devices, sizeof(EGLDeviceEXT));
if (!devices)
return NULL;
ret = eglQueryDevicesEXT(*num_devices, devices, num_devices);
if (!ret)
goto error;
/* We're only ever going to care about devices that support
* EGL_EXT_device_drm, so filter out the ones that don't
*/
for (i = 0; i < *num_devices; i++) {
const char *extension_str =
eglQueryDeviceStringEXT(devices[i], EGL_EXTENSIONS);
if (!epoxy_extension_in_string(extension_str, "EGL_EXT_device_drm"))
continue;
devices[drm_dev_count++] = devices[i];
}
if (!drm_dev_count)
goto error;
*num_devices = drm_dev_count;
xwayland: fix a realloc OOM error case Found by coverity Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2018-10-16 02:37:16 +02:00
tmp = realloc(devices, sizeof(EGLDeviceEXT) * drm_dev_count);
if (!tmp)
goto error;
devices = tmp;
xwayland: move glamor specific routines 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>
2018-06-05 19:38:36 +02:00
return devices;
error:
free(devices);
return NULL;
}
static Bool
xwl_glamor_egl_device_has_egl_extensions(void *device,
const char **ext_list, size_t size)
{
EGLDisplay egl_display;
int i;
Bool has_exts = TRUE;
egl_display = glamor_egl_get_display(EGL_PLATFORM_DEVICE_EXT, device);
if (!egl_display || !eglInitialize(egl_display, NULL, NULL))
return FALSE;
for (i = 0; i < size; i++) {
if (!epoxy_has_egl_extension(egl_display, ext_list[i])) {
has_exts = FALSE;
break;
}
}
eglTerminate(egl_display);
return has_exts;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
static void
xwayland/eglstream: Small refactoring 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>
2021-04-15 10:59:36 +02:00
xwl_eglstream_destroy_pixmap_stream(struct xwl_pixmap *xwl_pixmap)
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
{
struct xwl_screen *xwl_screen = xwl_pixmap->xwl_screen;
/* If we're using this stream in the current egl context, unbind it so the
* driver doesn't keep it around until the next eglMakeCurrent()
* don't have to keep it around until something else changes the surface
*/
xwl_glamor_egl_make_current(xwl_screen);
if (eglGetCurrentSurface(EGL_READ) == xwl_pixmap->surface ||
eglGetCurrentSurface(EGL_DRAW) == xwl_pixmap->surface) {
eglMakeCurrent(xwl_screen->egl_display,
EGL_NO_SURFACE, EGL_NO_SURFACE,
xwl_screen->egl_context);
}
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
if (xwl_pixmap->surface != EGL_NO_SURFACE)
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
eglDestroySurface(xwl_screen->egl_display, xwl_pixmap->surface);
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
if (xwl_pixmap->stream != EGL_NO_STREAM_KHR)
eglDestroyStreamKHR(xwl_screen->egl_display, xwl_pixmap->stream);
if (xwl_pixmap->buffer)
wl_buffer_destroy(xwl_pixmap->buffer);
if (xwl_pixmap->image != EGL_NO_IMAGE_KHR)
eglDestroyImageKHR(xwl_screen->egl_display, xwl_pixmap->image);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
free(xwl_pixmap);
}
xwayland/eglstream: Small refactoring 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>
2021-04-15 10:59:36 +02:00
static void
xwayland/eglstream: Consolidate pending_cb destruction Into a new xwl_eglstream_destroy_pending_stream helper. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
2021-07-02 12:57:21 +02:00
xwl_eglstream_destroy_pending_cb(PixmapPtr pixmap)
xwayland: Clean up pending eglstream on pixmap destroy 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
2020-11-02 10:24:45 +01:00
{
xwayland/eglstream: Consolidate pending_cb destruction Into a new xwl_eglstream_destroy_pending_stream helper. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
2021-07-02 12:57:21 +02:00
struct xwl_pixmap *xwl_pixmap = xwl_pixmap_get(pixmap);
if (xwl_pixmap && xwl_pixmap->pending_cb) {
xwayland/eglstream: Remove stream validity 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
2021-04-30 09:56:05 +02:00
wl_callback_destroy(xwl_pixmap->pending_cb);
xwl_pixmap->pending_cb = NULL;
xwayland: Clean up pending eglstream on pixmap destroy 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
2020-11-02 10:24:45 +01:00
}
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
static Bool
xwl_glamor_eglstream_destroy_pixmap(PixmapPtr pixmap)
{
struct xwl_pixmap *xwl_pixmap = xwl_pixmap_get(pixmap);
xwayland: Add buffer release callback 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>
2019-10-30 13:17:34 +01:00
if (xwl_pixmap && pixmap->refcnt == 1) {
xwayland/eglstream: Consolidate pending_cb destruction Into a new xwl_eglstream_destroy_pending_stream helper. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
2021-07-02 12:57:21 +02:00
xwl_eglstream_destroy_pending_cb(pixmap);
xwayland/eglstream: Small refactoring 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>
2021-04-15 10:59:36 +02:00
xwl_eglstream_destroy_pixmap_stream(xwl_pixmap);
xwayland: Add buffer release callback 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>
2019-10-30 13:17:34 +01:00
xwl_pixmap_del_buffer_release_cb(pixmap);
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
return glamor_destroy_pixmap(pixmap);
}
static struct wl_buffer *
xwayland: remove unused parameter of xwl_glamor_pixmap_get_wl_buffer 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.
2021-01-07 16:00:33 +01:00
xwl_glamor_eglstream_get_wl_buffer_for_pixmap(PixmapPtr pixmap)
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
{
xwayland/eglstream: Handle xwl_pixmap_get returning NULL 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: f3eb1684fa50 "xwayland: enable MIT-SHM shared pixmaps" Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
2021-05-18 17:56:50 +02:00
struct xwl_pixmap *xwl_pixmap = xwl_pixmap_get(pixmap);
if (!xwl_pixmap)
return NULL;
return xwl_pixmap->buffer;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
xwayland/eglstream: Add more error checking 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
2021-04-01 08:46:52 +02:00
static const char *
xwl_eglstream_get_error_str(EGLint error)
{
switch (error) {
case EGL_BAD_PARAMETER:
return "EGL_BAD_PARAMETER";
case EGL_BAD_ATTRIBUTE:
return "EGL_BAD_ATTRIBUTE";
case EGL_BAD_MATCH:
return "EGL_BAD_MATCH";
case EGL_BAD_ACCESS:
return "EGL_BAD_ACCESS";
case EGL_BAD_STATE_KHR:
return "EGL_BAD_STATE_KHR";
case EGL_BAD_STREAM_KHR:
return "EGL_BAD_STREAM_KHR";
case EGL_BAD_DISPLAY:
return "EGL_BAD_DISPLAY";
case EGL_NOT_INITIALIZED:
return "EGL_NOT_INITIALIZED";
default:
return "Unknown error";
}
}
static const char *
xwl_eglstream_get_stream_state_str(EGLint state)
{
switch (state) {
case EGL_STREAM_STATE_CREATED_KHR:
return "EGL_STREAM_STATE_CREATED_KHR";
case EGL_STREAM_STATE_CONNECTING_KHR:
return "EGL_STREAM_STATE_CONNECTING_KHR";
case EGL_STREAM_STATE_EMPTY_KHR:
return "EGL_STREAM_STATE_EMPTY_KHR";
case EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR:
return "EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR";
case EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR:
return "EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR";
case EGL_STREAM_STATE_DISCONNECTED_KHR:
return "EGL_STREAM_STATE_DISCONNECTED_KHR";
default:
return "Unknown state";
}
}
static EGLint
xwl_eglstream_get_state(EGLDisplay egl_display, EGLStreamKHR egl_stream)
{
EGLint state;
eglQueryStreamKHR(egl_display, egl_stream, EGL_STREAM_STATE_KHR, &state);
if (!eglQueryStreamKHR(egl_display, egl_stream,
EGL_STREAM_STATE_KHR, &state)) {
EGLint state_error = eglGetError();
ErrorF("eglstream: Failed to query state - error 0x%X: %s\n",
state_error, xwl_eglstream_get_error_str(state_error));
return EGL_FALSE;
}
return state;
}
static void
xwl_eglstream_print_error(EGLDisplay egl_display,
EGLStreamKHR egl_stream, EGLint error)
{
ErrorF("eglstream: error 0x%X: %s\n", error,
xwl_eglstream_get_error_str(error));
if (error == EGL_BAD_STATE_KHR) {
EGLint state = xwl_eglstream_get_state(egl_display, egl_stream);
ErrorF("eglstream: stream state 0x%X: %s\n", state,
xwl_eglstream_get_stream_state_str(state));
}
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
static void
xwl_eglstream_consumer_ready_callback(void *data,
struct wl_callback *callback,
uint32_t time)
{
xwayland/eglstream: Remove stream validity 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
2021-04-30 09:56:05 +02:00
PixmapPtr pixmap = data;
xwayland/eglstream: Drop the list of pending streams 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>
2021-04-27 14:17:19 +02:00
struct xwl_pixmap *xwl_pixmap = xwl_pixmap_get(pixmap);
struct xwl_screen *xwl_screen = xwl_pixmap->xwl_screen;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
xwayland/eglstream: Consolidate pending_cb destruction Into a new xwl_eglstream_destroy_pending_stream helper. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
2021-07-02 12:57:21 +02:00
xwl_eglstream_destroy_pending_cb(pixmap);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_glamor_egl_make_current(xwl_screen);
xwl_pixmap->surface = eglCreateStreamProducerSurfaceKHR(
xwl_screen->egl_display, xwl_eglstream->config,
xwl_pixmap->stream, (int[]) {
xwayland/eglstream: Dissociate pending stream from window 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
2021-04-16 10:38:23 +02:00
EGL_WIDTH, pixmap->drawable.width,
EGL_HEIGHT, pixmap->drawable.height,
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
EGL_NONE
});
xwayland/eglstream: Add more error checking 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
2021-04-01 08:46:52 +02:00
if (xwl_pixmap->surface == EGL_NO_SURFACE) {
ErrorF("eglstream: Failed to create EGLSurface for pixmap\n");
xwl_eglstream_print_error(xwl_screen->egl_display,
xwl_pixmap->stream, eglGetError());
xwayland/eglstream: Remove stream validity 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
2021-04-30 09:56:05 +02:00
} else {
DebugF("eglstream: completes eglstream for pixmap %p, congrats!\n",
pixmap);
xwayland/eglstream: Add more error checking 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
2021-04-01 08:46:52 +02:00
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
static const struct wl_callback_listener consumer_ready_listener = {
xwl_eglstream_consumer_ready_callback
};
static void
xwayland: Use the pixmap release callback with EGLStream 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>
2020-09-22 09:54:15 +02:00
xwl_eglstream_buffer_release_callback(void *data)
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
{
xwayland/eglstream: Do not always increment pixmap refcnt on commit 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>
2021-05-04 10:56:38 +02:00
PixmapPtr pixmap = data;
struct xwl_pixmap *xwl_pixmap = xwl_pixmap_get(pixmap);
assert(xwl_pixmap);
if (xwl_pixmap->wait_for_buffer_release) {
xwl_pixmap->wait_for_buffer_release = FALSE;
/* drop the reference we took in the ready callback, freeing if necessary */
dixDestroyPixmap(pixmap, 0);
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
static const struct wl_buffer_listener xwl_eglstream_buffer_release_listener = {
xwayland: Use the pixmap release callback with EGLStream 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>
2020-09-22 09:54:15 +02:00
xwl_pixmap_buffer_release_cb,
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
};
static void
xwayland/eglstream: Small refactoring 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>
2021-04-15 10:59:36 +02:00
xwl_eglstream_create_pixmap_and_stream(struct xwl_screen *xwl_screen,
WindowPtr window, PixmapPtr pixmap)
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
{
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
struct xwl_pixmap *xwl_pixmap;
struct xwl_window *xwl_window = xwl_window_from_window(window);
struct wl_array stream_attribs;
int stream_fd = -1;
xwayland/eglstream: Fix calloc/malloc 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>
2021-04-19 14:52:38 +02:00
xwl_pixmap = calloc(1, sizeof(*xwl_pixmap));
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
if (!xwl_pixmap)
FatalError("Not enough memory to create pixmap\n");
xwl_pixmap_set_private(pixmap, xwl_pixmap);
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
xwl_pixmap->type = XWL_PIXMAP_EGLSTREAM;
xwl_pixmap->image = EGL_NO_IMAGE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_glamor_egl_make_current(xwl_screen);
xwayland/eglstream: Do not always increment pixmap refcnt on commit 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>
2021-05-04 10:56:38 +02:00
xwl_pixmap->wait_for_buffer_release = FALSE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_pixmap->xwl_screen = xwl_screen;
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
xwl_pixmap->surface = EGL_NO_SURFACE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_pixmap->stream = eglCreateStreamKHR(xwl_screen->egl_display, NULL);
xwayland/eglstream: Add more error checking 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
2021-04-01 08:46:52 +02:00
if (xwl_pixmap->stream == EGL_NO_STREAM_KHR) {
ErrorF("eglstream: Couldn't create EGL stream.\n");
goto fail;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
stream_fd = eglGetStreamFileDescriptorKHR(xwl_screen->egl_display,
xwl_pixmap->stream);
xwayland/eglstream: Add more error checking 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
2021-04-01 08:46:52 +02:00
if (stream_fd == EGL_NO_FILE_DESCRIPTOR_KHR) {
ErrorF("eglstream: Couldn't get EGL stream file descriptor.\n");
goto fail;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
wl_array_init(&stream_attribs);
xwl_pixmap->buffer =
wl_eglstream_display_create_stream(xwl_eglstream->display,
pixmap->drawable.width,
pixmap->drawable.height,
stream_fd,
WL_EGLSTREAM_HANDLE_TYPE_FD,
&stream_attribs);
xwayland/eglstream: Check buffer creation 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
2021-03-29 14:22:56 +02:00
if (!xwl_pixmap->buffer) {
ErrorF("eglstream: Failed to create buffer\n");
goto fail;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
wl_buffer_add_listener(xwl_pixmap->buffer,
&xwl_eglstream_buffer_release_listener,
xwayland: Add buffer release callback 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>
2019-10-30 13:17:34 +01:00
pixmap);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwayland: Use the pixmap release callback with EGLStream 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>
2020-09-22 09:54:15 +02:00
xwl_pixmap_set_buffer_release_cb(pixmap,
xwl_eglstream_buffer_release_callback,
pixmap);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
wl_eglstream_controller_attach_eglstream_consumer(
xwl_eglstream->controller, xwl_window->surface, xwl_pixmap->buffer);
xwayland/eglstream: Remove stream validity 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
2021-04-30 09:56:05 +02:00
xwl_pixmap->pending_cb = wl_display_sync(xwl_screen->display);
wl_callback_add_listener(xwl_pixmap->pending_cb, &consumer_ready_listener,
pixmap);
xwayland/eglstream: Check buffer creation 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
2021-03-29 14:22:56 +02:00
fail:
if (stream_fd >= 0)
close(stream_fd);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
static Bool
xwl_glamor_eglstream_allow_commits(struct xwl_window *xwl_window)
{
struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
PixmapPtr pixmap =
(*xwl_screen->screen->GetWindowPixmap)(xwl_window->window);
struct xwl_pixmap *xwl_pixmap = xwl_pixmap_get(pixmap);
if (xwl_pixmap) {
xwayland/eglstream: Remove stream validity 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
2021-04-30 09:56:05 +02:00
if (xwl_pixmap->pending_cb) {
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
/* Wait for the compositor to finish connecting the consumer for
* this eglstream */
xwayland/eglstream: Dissociate pending stream from window 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
2021-04-16 10:38:23 +02:00
return FALSE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
xwayland/eglstream: Remove stream validity 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
2021-04-30 09:56:05 +02:00
if (xwl_pixmap->surface != EGL_NO_SURFACE ||
xwl_pixmap->type == XWL_PIXMAP_DMA_BUF) {
return TRUE;
}
/* The pending stream got removed, we have a xwl_pixmap and
* yet we do not have a surface.
* So something went wrong with the surface creation, retry.
*/
xwl_eglstream_destroy_pixmap_stream(xwl_pixmap);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
/* Glamor pixmap has no backing stream yet; begin making one and disallow
* commits until then
*/
xwayland/eglstream: Small refactoring 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>
2021-04-15 10:59:36 +02:00
xwl_eglstream_create_pixmap_and_stream(xwl_screen, xwl_window->window,
pixmap);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
return FALSE;
}
xwayland/glamor: Add return status to post_damage 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
2021-03-31 13:57:45 +02:00
static Bool
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_glamor_eglstream_post_damage(struct xwl_window *xwl_window,
PixmapPtr pixmap, RegionPtr region)
{
struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
struct xwl_pixmap *xwl_pixmap = xwl_pixmap_get(pixmap);
BoxPtr box = RegionExtents(region);
EGLint egl_damage[] = {
box->x1, box->y1,
box->x2 - box->x1, box->y2 - box->y1
};
GLint saved_vao;
xwayland/eglstream: Check framebuffer status 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
2021-03-31 09:49:35 +02:00
int status;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwayland-eglstream: fix X11 rendering to flipping GL / VK window 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>
2021-04-27 13:23:44 +02:00
if (xwl_pixmap->type != XWL_PIXMAP_EGLSTREAM)
/* This can happen if a client does X11 rendering on a
* flipping OpenGL or Vulkan window. In that case, we don't
* need to do the copy below.
*/
xwayland/glamor: Add return status to post_damage 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
2021-03-31 13:57:45 +02:00
return TRUE;
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
/* Unbind the framebuffer BEFORE binding the EGLSurface, otherwise we
* won't actually draw to it
*/
xwl_glamor_egl_make_current(xwl_screen);
xwayland/eglstream: Set ALU to GXCopy for blitting 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>
2021-04-30 16:23:10 +02:00
glamor_set_alu(xwl_screen->screen, GXcopy);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
glBindFramebuffer(GL_FRAMEBUFFER, 0);
if (eglGetCurrentSurface(EGL_READ) != xwl_pixmap->surface ||
eglGetCurrentSurface(EGL_DRAW) != xwl_pixmap->surface)
eglMakeCurrent(xwl_screen->egl_display,
xwl_pixmap->surface, xwl_pixmap->surface,
xwl_screen->egl_context);
/* Save current GL state */
glGetIntegerv(GL_VERTEX_ARRAY_BINDING, &saved_vao);
/* Setup our GL state */
glUseProgram(xwl_eglstream->blit_prog);
glViewport(0, 0, pixmap->drawable.width, pixmap->drawable.height);
glActiveTexture(GL_TEXTURE0);
glBindVertexArray(xwl_eglstream->blit_vao);
glBindTexture(GL_TEXTURE_2D, glamor_get_pixmap_texture(pixmap));
glUniform1i(xwl_eglstream->blit_is_rgba_pos,
pixmap->drawable.depth >= 32);
xwayland/eglstream: Check framebuffer status 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
2021-03-31 09:49:35 +02:00
status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (status != GL_FRAMEBUFFER_COMPLETE) {
ErrorF("eglstream: Framebuffer incomplete 0x%X, not posting damage\n", status);
status = FALSE;
goto out;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
/* Blit rendered image into EGLStream surface */
glDrawBuffer(GL_BACK);
glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
if (xwl_eglstream->have_egl_damage)
xwayland/eglstream: Check eglSwapBuffers() 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>
2021-04-30 09:02:29 +02:00
status = eglSwapBuffersWithDamageKHR(xwl_screen->egl_display,
xwl_pixmap->surface,
egl_damage, 1);
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
else
xwayland/eglstream: Check eglSwapBuffers() 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>
2021-04-30 09:02:29 +02:00
status = eglSwapBuffers(xwl_screen->egl_display,
xwl_pixmap->surface);
if (!status) {
ErrorF("eglstream: buffer swap failed, not posting damage\n");
goto out;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwayland/eglstream: flush stream after eglSwapBuffers 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>
2021-05-11 23:00:21 +02:00
#ifdef EGL_NV_stream_flush
if (xwl_eglstream->have_egl_stream_flush)
/* block until stream state is updated on the compositor's side */
eglStreamFlushNV(xwl_screen->egl_display,
xwl_pixmap->stream);
#endif
xwayland/eglstream: Do not always increment pixmap refcnt on commit 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>
2021-05-04 10:56:38 +02:00
if (!xwl_pixmap->wait_for_buffer_release) {
/* hang onto the pixmap until the compositor has released it */
pixmap->refcnt++;
xwl_pixmap->wait_for_buffer_release = TRUE;
}
xwayland/eglstream: Check framebuffer status 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
2021-03-31 09:49:35 +02:00
out:
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
/* Restore previous state */
glBindVertexArray(saved_vao);
glBindTexture(GL_TEXTURE_2D, 0);
xwayland/eglstream: Check framebuffer status 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
2021-03-31 09:49:35 +02:00
return status;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
xwayland: Add check_flip() glamor backend function 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>
2021-03-03 11:56:41 +01:00
static Bool
xwl_glamor_eglstream_check_flip(PixmapPtr pixmap)
{
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
return xwl_pixmap_get(pixmap)->type == XWL_PIXMAP_DMA_BUF;
xwayland: Add check_flip() glamor backend function 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>
2021-03-03 11:56:41 +01:00
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
static void
xwl_eglstream_display_handle_caps(void *data,
struct wl_eglstream_display *disp,
int32_t caps)
{
xwl_eglstream_get(data)->display_caps = caps;
}
static void
xwl_eglstream_display_handle_swapinterval_override(void *data,
struct wl_eglstream_display *disp,
int32_t swapinterval,
struct wl_buffer *stream)
{
}
const struct wl_eglstream_display_listener eglstream_display_listener = {
.caps = xwl_eglstream_display_handle_caps,
.swapinterval_override = xwl_eglstream_display_handle_swapinterval_override,
};
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
static Bool
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_glamor_eglstream_init_wl_registry(struct xwl_screen *xwl_screen,
struct wl_registry *wl_registry,
xwayland: swap "name" and "id" in init_wl_registry() 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>
2018-06-05 19:38:37 +02:00
uint32_t id, const char *name,
uint32_t version)
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
{
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
if (strcmp(name, "wl_eglstream_display") == 0) {
xwl_eglstream->display = wl_registry_bind(
wl_registry, id, &wl_eglstream_display_interface, version);
wl_eglstream_display_add_listener(xwl_eglstream->display,
&eglstream_display_listener,
xwl_screen);
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
return TRUE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
} else if (strcmp(name, "wl_eglstream_controller") == 0) {
xwl_eglstream->controller = wl_registry_bind(
wl_registry, id, &wl_eglstream_controller_interface, version);
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
return TRUE;
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
} else if (strcmp(name, "zwp_linux_dmabuf_v1") == 0) {
xwl_screen_set_dmabuf_interface(xwl_screen, id, version);
return TRUE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
/* no match */
return FALSE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
xwayland: Add Wayland interfaces check 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>
2018-06-05 19:38:41 +02:00
static Bool
xwl_glamor_eglstream_has_wl_interfaces(struct xwl_screen *xwl_screen)
{
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
if (xwl_eglstream->display == NULL) {
ErrorF("glamor: 'wl_eglstream_display' not supported\n");
return FALSE;
}
if (xwl_eglstream->controller == NULL) {
ErrorF("glamor: 'wl_eglstream_controller' not supported\n");
return FALSE;
}
return TRUE;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
static inline void
xwl_eglstream_init_shaders(struct xwl_screen *xwl_screen)
{
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
GLint fs, vs, attrib;
GLuint vbo;
const char *blit_vs_src =
"attribute vec2 texcoord;\n"
"attribute vec2 position;\n"
"varying vec2 t;\n"
"void main() {\n"
" t = texcoord;\n"
" gl_Position = vec4(position, 0, 1);\n"
"}";
const char *blit_fs_src =
"varying vec2 t;\n"
"uniform sampler2D s;\n"
"uniform bool is_rgba;\n"
"void main() {\n"
" if (is_rgba)\n"
" gl_FragColor = texture2D(s, t);\n"
" else\n"
" gl_FragColor = vec4(texture2D(s, t).rgb, 1.0);\n"
"}";
static const float position[] = {
/* position */
-1, -1,
1, -1,
1, 1,
-1, 1,
/* texcoord */
0, 1,
1, 1,
1, 0,
0, 0,
};
vs = xwl_eglstream_compile_glsl_prog(GL_VERTEX_SHADER, blit_vs_src);
fs = xwl_eglstream_compile_glsl_prog(GL_FRAGMENT_SHADER, blit_fs_src);
xwl_eglstream->blit_prog = xwl_eglstream_build_glsl_prog(vs, fs);
glDeleteShader(vs);
glDeleteShader(fs);
/* Create the blitter's vao */
glGenVertexArrays(1, &xwl_eglstream->blit_vao);
glBindVertexArray(xwl_eglstream->blit_vao);
/* Set the data for both position and texcoord in the vbo */
glGenBuffers(1, &vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(position), position, GL_STATIC_DRAW);
xwl_eglstream->blit_vbo = vbo;
/* Define each shader attribute's data location in our vbo */
attrib = glGetAttribLocation(xwl_eglstream->blit_prog, "position");
glVertexAttribPointer(attrib, 2, GL_FLOAT, TRUE, 0, NULL);
glEnableVertexAttribArray(attrib);
attrib = glGetAttribLocation(xwl_eglstream->blit_prog, "texcoord");
glVertexAttribPointer(attrib, 2, GL_FLOAT, TRUE, 0,
(void*)(sizeof(float) * 8));
glEnableVertexAttribArray(attrib);
/* Save the location of uniforms we'll set later */
xwl_eglstream->blit_is_rgba_pos =
glGetUniformLocation(xwl_eglstream->blit_prog, "is_rgba");
}
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
static int
xwl_dri3_open_client(ClientPtr client,
ScreenPtr screen,
RRProviderPtr provider,
int *pfd)
{
/* Not supported with this backend. */
return BadImplementation;
}
static PixmapPtr
xwl_dri3_pixmap_from_fds(ScreenPtr screen,
CARD8 num_fds, const int *fds,
CARD16 width, CARD16 height,
const CARD32 *strides, const CARD32 *offsets,
CARD8 depth, CARD8 bpp,
uint64_t modifier)
{
PixmapPtr pixmap;
struct xwl_screen *xwl_screen = xwl_screen_get(screen);
struct xwl_pixmap *xwl_pixmap;
unsigned int texture;
EGLint image_attribs[48];
uint32_t mod_hi = modifier >> 32, mod_lo = modifier & 0xffffffff, format;
int attrib = 0, i;
struct zwp_linux_buffer_params_v1 *params;
format = wl_drm_format_for_depth(depth);
if (!xwl_glamor_is_modifier_supported(xwl_screen, format, modifier)) {
ErrorF("glamor: unsupported format modifier\n");
return NULL;
}
xwl_pixmap = calloc(1, sizeof (*xwl_pixmap));
if (!xwl_pixmap)
return NULL;
xwl_pixmap->type = XWL_PIXMAP_DMA_BUF;
xwl_pixmap->xwl_screen = xwl_screen;
xwl_pixmap->buffer = NULL;
xwl_pixmap->stream = EGL_NO_STREAM_KHR;
xwl_pixmap->surface = EGL_NO_SURFACE;
params = zwp_linux_dmabuf_v1_create_params(xwl_screen->dmabuf);
for (i = 0; i < num_fds; i++) {
zwp_linux_buffer_params_v1_add(params, fds[i], i,
offsets[i], strides[i],
mod_hi, mod_lo);
}
xwl_pixmap->buffer =
zwp_linux_buffer_params_v1_create_immed(params, width, height,
format, 0);
zwp_linux_buffer_params_v1_destroy(params);
image_attribs[attrib++] = EGL_WIDTH;
image_attribs[attrib++] = width;
image_attribs[attrib++] = EGL_HEIGHT;
image_attribs[attrib++] = height;
image_attribs[attrib++] = EGL_LINUX_DRM_FOURCC_EXT;
image_attribs[attrib++] = drm_format_for_depth(depth, bpp);
if (num_fds > 0) {
image_attribs[attrib++] = EGL_DMA_BUF_PLANE0_FD_EXT;
image_attribs[attrib++] = fds[0];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE0_OFFSET_EXT;
image_attribs[attrib++] = offsets[0];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE0_PITCH_EXT;
image_attribs[attrib++] = strides[0];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT;
image_attribs[attrib++] = mod_hi;
image_attribs[attrib++] = EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT;
image_attribs[attrib++] = mod_lo;
}
if (num_fds > 1) {
image_attribs[attrib++] = EGL_DMA_BUF_PLANE1_FD_EXT;
image_attribs[attrib++] = fds[1];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE1_OFFSET_EXT;
image_attribs[attrib++] = offsets[1];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE1_PITCH_EXT;
image_attribs[attrib++] = strides[1];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE1_MODIFIER_HI_EXT;
image_attribs[attrib++] = mod_hi;
image_attribs[attrib++] = EGL_DMA_BUF_PLANE1_MODIFIER_LO_EXT;
image_attribs[attrib++] = mod_lo;
}
if (num_fds > 2) {
image_attribs[attrib++] = EGL_DMA_BUF_PLANE2_FD_EXT;
image_attribs[attrib++] = fds[2];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE2_OFFSET_EXT;
image_attribs[attrib++] = offsets[2];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE2_PITCH_EXT;
image_attribs[attrib++] = strides[2];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE2_MODIFIER_HI_EXT;
image_attribs[attrib++] = mod_hi;
image_attribs[attrib++] = EGL_DMA_BUF_PLANE2_MODIFIER_LO_EXT;
image_attribs[attrib++] = mod_lo;
}
if (num_fds > 3) {
image_attribs[attrib++] = EGL_DMA_BUF_PLANE3_FD_EXT;
image_attribs[attrib++] = fds[3];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE3_OFFSET_EXT;
image_attribs[attrib++] = offsets[3];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE3_PITCH_EXT;
image_attribs[attrib++] = strides[3];
image_attribs[attrib++] = EGL_DMA_BUF_PLANE3_MODIFIER_HI_EXT;
image_attribs[attrib++] = mod_hi;
image_attribs[attrib++] = EGL_DMA_BUF_PLANE3_MODIFIER_LO_EXT;
image_attribs[attrib++] = mod_lo;
}
image_attribs[attrib++] = EGL_NONE;
xwl_glamor_egl_make_current(xwl_screen);
/* eglCreateImageKHR will close fds */
xwl_pixmap->image = eglCreateImageKHR(xwl_screen->egl_display,
EGL_NO_CONTEXT,
EGL_LINUX_DMA_BUF_EXT,
NULL, image_attribs);
if (xwl_pixmap->image == EGL_NO_IMAGE_KHR) {
ErrorF("eglCreateImageKHR failed!\n");
if (xwl_pixmap->buffer)
wl_buffer_destroy(xwl_pixmap->buffer);
free(xwl_pixmap);
return NULL;
}
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, xwl_pixmap->image);
glBindTexture(GL_TEXTURE_2D, 0);
pixmap = glamor_create_pixmap(screen, width, height, depth,
GLAMOR_CREATE_PIXMAP_NO_TEXTURE);
glamor_set_pixmap_texture(pixmap, texture);
glamor_set_pixmap_type(pixmap, GLAMOR_TEXTURE_DRM);
wl_buffer_add_listener(xwl_pixmap->buffer,
&xwl_eglstream_buffer_release_listener,
pixmap);
xwl_pixmap_set_private(pixmap, xwl_pixmap);
return pixmap;
}
static const dri3_screen_info_rec xwl_dri3_info = {
.version = 2,
.open = NULL,
.pixmap_from_fds = xwl_dri3_pixmap_from_fds,
.fds_from_pixmap = NULL,
.open_client = xwl_dri3_open_client,
.get_formats = xwl_glamor_get_formats,
.get_modifiers = xwl_glamor_get_modifiers,
.get_drawable_modifiers = glamor_get_drawable_modifiers,
};
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
static Bool
xwl_glamor_eglstream_init_egl(struct xwl_screen *xwl_screen)
{
struct xwl_eglstream_private *xwl_eglstream =
xwl_eglstream_get(xwl_screen);
EGLConfig config;
const EGLint attrib_list[] = {
EGL_CONTEXT_OPENGL_PROFILE_MASK_KHR,
EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR,
EGL_CONTEXT_MAJOR_VERSION_KHR,
GLAMOR_GL_CORE_VER_MAJOR,
EGL_CONTEXT_MINOR_VERSION_KHR,
GLAMOR_GL_CORE_VER_MINOR,
EGL_CONTEXT_PRIORITY_LEVEL_IMG, EGL_CONTEXT_PRIORITY_HIGH_IMG,
EGL_NONE
};
const EGLint config_attribs[] = {
EGL_SURFACE_TYPE, EGL_STREAM_BIT_KHR,
EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT,
EGL_RED_SIZE, 8,
EGL_GREEN_SIZE, 8,
EGL_BLUE_SIZE, 8,
EGL_ALPHA_SIZE, 8,
EGL_NONE,
};
int n;
xwl_screen->egl_display = glamor_egl_get_display(
EGL_PLATFORM_DEVICE_EXT, xwl_eglstream->egl_device);
if (!xwl_screen->egl_display)
goto error;
if (!eglInitialize(xwl_screen->egl_display, NULL, NULL)) {
xwl_screen->egl_display = NULL;
goto error;
}
xwayland: EGL_IMG_context_priority required by EGLStream 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>
2018-06-05 19:38:45 +02:00
if (!epoxy_has_egl_extension(xwl_screen->egl_display,
"EGL_IMG_context_priority")) {
ErrorF("EGL_IMG_context_priority not available\n");
goto error;
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
eglChooseConfig(xwl_screen->egl_display, config_attribs, &config, 1, &n);
if (!n) {
ErrorF("No acceptable EGL configs found\n");
goto error;
}
xwl_eglstream->config = config;
#if 0
xwl_screen->formats =
XWL_FORMAT_RGB565 | XWL_FORMAT_XRGB8888 | XWL_FORMAT_ARGB8888;
#endif
eglBindAPI(EGL_OPENGL_API);
xwl_screen->egl_context = eglCreateContext(
xwl_screen->egl_display, config, EGL_NO_CONTEXT, attrib_list);
if (xwl_screen->egl_context == EGL_NO_CONTEXT) {
ErrorF("Failed to create main EGL context: 0x%x\n", eglGetError());
goto error;
}
if (!eglMakeCurrent(xwl_screen->egl_display,
EGL_NO_SURFACE, EGL_NO_SURFACE,
xwl_screen->egl_context)) {
ErrorF("Failed to make EGL context current\n");
goto error;
}
xwl_eglstream->have_egl_damage =
epoxy_has_egl_extension(xwl_screen->egl_display,
"EGL_KHR_swap_buffers_with_damage");
if (!xwl_eglstream->have_egl_damage)
ErrorF("Driver lacks EGL_KHR_swap_buffers_with_damage, performance "
"will be affected\n");
xwayland/eglstream: flush stream after eglSwapBuffers 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>
2021-05-11 23:00:21 +02:00
#ifdef EGL_NV_stream_flush
xwl_eglstream->have_egl_stream_flush =
epoxy_has_egl_extension(xwl_screen->egl_display,
"EGL_NV_stream_flush");
#else
xwl_eglstream->have_egl_stream_flush = FALSE;
#endif /* EGL_NV_stream_flush */
if (!xwl_eglstream->have_egl_stream_flush)
ErrorF("EGL_NV_stream_flush not available, "
"this may cause visible corruption.\n");
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_eglstream_init_shaders(xwl_screen);
xwayland/eglstream: Use "nvidia" for GLVND 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>
2021-05-17 18:20:57 +02:00
if (epoxy_has_gl_extension("GL_OES_EGL_image")) {
if (dri3_screen_init(xwl_screen->screen, &xwl_dri3_info))
xwl_screen->glvnd_vendor = "nvidia";
else
ErrorF("DRI3 initialization failed. Performance will be affected.\n");
xwayland/eglstream: Log when GL_OES_EGL_image is missing 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>
2021-05-20 16:46:33 +02:00
} else {
ErrorF("Driver lacks GL_OES_EGL_image, performance will be affected.\n");
xwayland: implement pixmap_from_buffers for the eglstream backend 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>
2020-12-03 23:57:51 +01:00
}
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
return TRUE;
error:
xwl_eglstream_cleanup(xwl_screen);
return FALSE;
}
static Bool
xwl_glamor_eglstream_init_screen(struct xwl_screen *xwl_screen)
{
ScreenPtr screen = xwl_screen->screen;
/* We can just let glamor handle CreatePixmap */
screen->DestroyPixmap = xwl_glamor_eglstream_destroy_pixmap;
return TRUE;
}
static EGLDeviceEXT
xwl_eglstream_get_device(struct xwl_screen *xwl_screen)
{
void **devices = NULL;
const char *exts[] = {
"EGL_KHR_stream",
"EGL_KHR_stream_producer_eglsurface",
};
int num_devices, i;
EGLDeviceEXT device = EGL_NO_DEVICE_EXT;
/* No device specified by the user, so find one ourselves */
devices = xwl_glamor_egl_get_devices(&num_devices);
if (!devices)
goto out;
for (i = 0; i < num_devices; i++) {
if (xwl_glamor_egl_device_has_egl_extensions(devices[i], exts,
ARRAY_SIZE(exts))) {
device = devices[i];
break;
}
}
free(devices);
out:
if (!device)
ErrorF("glamor: No eglstream capable devices found\n");
return device;
}
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
void
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwl_glamor_init_eglstream(struct xwl_screen *xwl_screen)
{
struct xwl_eglstream_private *xwl_eglstream;
EGLDeviceEXT egl_device;
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
xwl_screen->eglstream_backend.is_available = FALSE;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
egl_device = xwl_eglstream_get_device(xwl_screen);
if (egl_device == EGL_NO_DEVICE_EXT)
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
return;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
if (!dixRegisterPrivateKey(&xwl_eglstream_private_key, PRIVATE_SCREEN, 0))
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
return;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
xwayland/eglstream: Fix order of `calloc()` args 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>
2019-10-31 09:04:19 +01:00
xwl_eglstream = calloc(1, sizeof(*xwl_eglstream));
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
if (!xwl_eglstream) {
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
ErrorF("Failed to allocate memory required to init EGLStream support\n");
return;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}
dixSetPrivate(&xwl_screen->screen->devPrivates,
&xwl_eglstream_private_key, xwl_eglstream);
xwl_eglstream->egl_device = egl_device;
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
xwl_screen->eglstream_backend.init_egl = xwl_glamor_eglstream_init_egl;
xwl_screen->eglstream_backend.init_wl_registry = xwl_glamor_eglstream_init_wl_registry;
xwl_screen->eglstream_backend.has_wl_interfaces = xwl_glamor_eglstream_has_wl_interfaces;
xwl_screen->eglstream_backend.init_screen = xwl_glamor_eglstream_init_screen;
xwl_screen->eglstream_backend.get_wl_buffer_for_pixmap = xwl_glamor_eglstream_get_wl_buffer_for_pixmap;
xwl_screen->eglstream_backend.post_damage = xwl_glamor_eglstream_post_damage;
xwl_screen->eglstream_backend.allow_commits = xwl_glamor_eglstream_allow_commits;
xwayland: Add check_flip() glamor backend function 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>
2021-03-03 11:56:41 +01:00
xwl_screen->eglstream_backend.check_flip = xwl_glamor_eglstream_check_flip;
xwayland: refactor EGL backends for wayland registry 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>
2018-06-05 19:38:43 +02:00
xwl_screen->eglstream_backend.is_available = TRUE;
xwayland: Add a flag to expose EGL backend features 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>
2020-09-14 14:26:34 +02:00
xwl_screen->eglstream_backend.backend_flags = XWL_EGL_BACKEND_NO_FLAG;
xwayland: Add glamor egl_backend for EGLStreams 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>
2018-04-20 20:38:05 +02:00
}