fdo-mirrors/xserver
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/xorg/xserver.git synced 2025-12-20 15:10:02 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
xserver/include/xwayland-config.h.meson.in

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

21 lines
431 B
Text
Raw Permalink Normal View History

xwayland: Add xwayland-config.h Just a small autogenerated header that will soon contain more then just one macro. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2018-04-20 14:38:04 -04:00
/* xwayland-config.h.meson.in: not at all generated */
#pragma once
#include <dix-config.h>
/* Build glamor support for Xwayland */
#mesondefine XWL_HAS_GLAMOR
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 14:38:05 -04:00
xwayland: add optional support for libdecor When running rootful, the Xwayland window is not decorated (as all Wayland surfaces), which makes it quite inconvenient to move on screen. libdecor is "a client-side decorations library for Wayland clients" which can be used precisely for adding decorations to Wayland surfaces. Add optional support for libdecor in Xwayland to gain decorations when running rootful and a new command line option "-decorate". Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1332
2022-05-04 14:42:41 +02:00
/* Build Xwayland with libdecor support*/
#mesondefine XWL_HAS_LIBDECOR
xwayland: add support for the XWAYLAND extension This extension exists to serve one purpose: reliably identifying Xwayland. Previous attempts at doing so included querying root window properties, output names or input device names. All these attempts are somewhat unreliable. Instead, let's use an extension - where that extension is present we have an Xwayland server. Clients should never need to do anything but check whether the extension exists through XQueryExtension or search through XListExtensions. This extension provides a single QueryVersion request only, and that is only to provide future compatibility if we ever need anything other than "this extension exists" functionality. https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/54 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-07-28 12:22:14 +10:00
/* Build Xwayland with XWAYLAND extension */
#mesondefine XWL_HAS_XWAYLAND_EXTENSION
xwayland: Add XTEST support using EIS This adds support for XTEST in Xwayland using EIS, the emulated input library [1]. To differentiate between X11 clients using XTEST, initiate a EI context for each client and use the actual client name, from its command line. When an X11 client first tries to use XTEST to generate emulated input events, a new connection to libEI is initiated by Xwayland on behalf of the X11 client. During that connection phase, the EI server will not be accepting events until the emulated device is actually created, meaning that any XTEST request from the X11 client will be discarded until the EI server is willing to accept events. To avoid that issue, add an event queue in Xwayland per X11 client that will keep those requests, and dequeue them as soon as the EI server is ready, i.e. once the EI device is added. If the X11 client disconnects from the Xserver before the EI server is ready, or if the connection is closed by the EI server, those events are discarded and the queue cleared from any pending events. For 10 minutes after the client disconnects, keep the internal struct alive. If a client with the same commandline arguments connects again, re-use the same struct. This means we are faster with the events the second time around but it also allows the EIS server to pause individual clients that keep sending intermittent events and disconnect immediately (e.g. it'd be possible to pause xdtotool while an authentication prompt is active). [1] https://gitlab.freedesktop.org/libinput/libei Thanks to Jan Beich <jbeich@FreeBSD.org> for fixing the build on BSD. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Co-authored-by: Olivier Fourdan <ofourdan@redhat.com> Co-authored-by: David Redondo <kde@david-redondo.de> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
2020-09-04 12:44:15 +10:00
/* Enable EI */
#mesondefine XWL_HAS_EI
/* Enable XDG portal integration */
#mesondefine XWL_HAS_EI_PORTAL
Reference in a new issue Copy permalink