xserver-multidpi/hw/xwayland/xwayland.c

256 lines
6.8 KiB
C
Raw Normal View History

/*
* Copyright © 2011-2014 Intel Corporation
*
* Permission to use, copy, modify, distribute, and sell this software
* and its documentation for any purpose is hereby granted without
* fee, provided that the above copyright notice appear in all copies
* and that both that copyright notice and this permission notice
* appear in supporting documentation, and that the name of the
* copyright holders not be used in advertising or publicity
* pertaining to distribution of the software without specific,
* written prior permission. The copyright holders make no
* representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied
* warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
* SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
* SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
* AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
* OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
* SOFTWARE.
*/
#include <stdio.h>
xwayland: use _XWAYLAND_ALLOW_COMMITS property The X11 window manager (XWM) of a Wayland compositor can use the _XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends wl_surface.commit requests. If the property is not set, the behaviour remains what it was. XWM uses the property to inhibit commits until the window is ready to be shown. This gives XWM time to set up the window decorations and internal state before Xwayland does the first commit. XWM can use this to ensure the first commit carries fully drawn decorations and the window management state is correct when the window becomes visible. Setting the property to zero inhibits further commits, and setting it to non-zero allows commits. Deleting the property allows commits. When the property is changed from zero to non-zero, there will be a commit on next block_handler() call provided that some damage has been recorded. Without this patch (i.e. with the old behaviour) Xwayland can and will commit the surface very soon as the application window has been realized and drawn into. This races with XWM and may cause visible glitches. v3: - introduced a simple setter for xwl_window::allow_commits - split xwl_window_property_allow_commits() out of xwl_property_callback() - check MakeAtom(_XWAYLAND_ALLOW_COMMITS) v2: - use PropertyStateCallback instead of XACE, based on the patch "xwayland: Track per-window support for netwm frame sync" by Adam Jackson - check property type is XA_CARDINAL - drop a useless memcpy() Weston Bug: https://phabricator.freedesktop.org/T7622 Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2016-11-23 12:30:53 +01:00
#include <X11/Xatom.h>
#include <selection.h>
#include <micmap.h>
#include <misyncshm.h>
#include <compositeext.h>
#include <compint.h>
#include <glx_extinit.h>
#include <os.h>
xwayland: handle EAGAIN on Wayland fd wl_display_flush() can fail with EAGAIN and Xwayland would make this a fatal error. When this happens, it means that Xwayland has flooded the Wayland file descriptor, either because the Wayland compositor cannot cope or more likely because of a deadlock situation where the Wayland compositor is blocking, waiting for an X reply while Xwayland tries to write data to the Wayland file descriptor. The general consensus to avoid the deadlock is for the Wayland compositor to never issue blocking X11 roundtrips, but in practice blocking rountrips can occur in various places, including Xlib calls themselves so this is not always achievable without major surgery in the Wayland compositor/Window manager. What this patch does is to avoid dispatching to the Wayland file descriptor until it becomes available for writing again, while at the same time continue processing X11 requests to release the deadlock. This is not perfect, as there is still the possibility of another X client hammering the connection and we'll still fail writing to the Wayland connection eventually, but this improves things enough to avoid a 100% repeatable crash with vlc and gtkperf. Also, it is worth considering that window managers and Wayland compositors such as mutter already have a higher priority than other regular X clients thanks to XSyncSetPriority(), mitigating the risk. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1278159 Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763400 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-09-15 15:59:07 +02:00
#include <xserver_poll.h>
xwayland: use _XWAYLAND_ALLOW_COMMITS property The X11 window manager (XWM) of a Wayland compositor can use the _XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends wl_surface.commit requests. If the property is not set, the behaviour remains what it was. XWM uses the property to inhibit commits until the window is ready to be shown. This gives XWM time to set up the window decorations and internal state before Xwayland does the first commit. XWM can use this to ensure the first commit carries fully drawn decorations and the window management state is correct when the window becomes visible. Setting the property to zero inhibits further commits, and setting it to non-zero allows commits. Deleting the property allows commits. When the property is changed from zero to non-zero, there will be a commit on next block_handler() call provided that some damage has been recorded. Without this patch (i.e. with the old behaviour) Xwayland can and will commit the surface very soon as the application window has been realized and drawn into. This races with XWM and may cause visible glitches. v3: - introduced a simple setter for xwl_window::allow_commits - split xwl_window_property_allow_commits() out of xwl_property_callback() - check MakeAtom(_XWAYLAND_ALLOW_COMMITS) v2: - use PropertyStateCallback instead of XACE, based on the patch "xwayland: Track per-window support for netwm frame sync" by Adam Jackson - check property type is XA_CARDINAL - drop a useless memcpy() Weston Bug: https://phabricator.freedesktop.org/T7622 Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2016-11-23 12:30:53 +01:00
#include <propertyst.h>
#include "xwayland.h"
#include "xwayland-screen.h"
#include "xwayland-vidmode.h"
#ifdef XF86VIDMODE
#include <X11/extensions/xf86vmproto.h>
_X_EXPORT Bool noXFree86VidModeExtension;
#endif
void
ddxGiveUp(enum ExitCode error)
{
}
void
OsVendorInit(void)
{
if (serverGeneration == 1)
ForceClockId(CLOCK_MONOTONIC);
}
void
OsVendorFatalError(const char *f, va_list args)
{
}
#if defined(DDXBEFORERESET)
void
ddxBeforeReset(void)
{
return;
}
#endif
#if INPUTTHREAD
/** This function is called in Xserver/os/inputthread.c when starting
the input thread. */
void
ddxInputThreadInit(void)
{
}
#endif
void
ddxUseMsg(void)
{
ErrorF("-rootless run rootless, requires wm support\n");
ErrorF("-wm fd create X client for wm on given fd\n");
ErrorF("-initfd fd add given fd as a listen socket for initialization clients\n");
ErrorF("-listenfd fd add given fd as a listen socket\n");
ErrorF("-listen fd deprecated, use \"-listenfd\" instead\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
ErrorF("-eglstream use eglstream backend for nvidia GPUs\n");
}
static int init_fd = -1;
static int wm_fd = -1;
static int listen_fds[5] = { -1, -1, -1, -1, -1 };
static int listen_fd_count = 0;
static void
xwl_add_listen_fd(int argc, char *argv[], int i)
{
NoListenAll = TRUE;
if (listen_fd_count == ARRAY_SIZE(listen_fds))
FatalError("Too many -listen arguments given, max is %zu\n",
ARRAY_SIZE(listen_fds));
listen_fds[listen_fd_count++] = atoi(argv[i + 1]);
}
int
ddxProcessArgument(int argc, char *argv[], int i)
{
if (strcmp(argv[i], "-rootless") == 0) {
return 1;
}
else if (strcmp(argv[i], "-listen") == 0) {
CHECK_FOR_REQUIRED_ARGUMENTS(1);
/* Not an FD */
if (!isdigit(*argv[i + 1]))
return 0;
LogMessage(X_WARNING, "Option \"-listen\" for file descriptors is deprecated\n"
"Please use \"-listenfd\" instead.\n");
xwl_add_listen_fd (argc, argv, i);
return 2;
}
else if (strcmp(argv[i], "-listenfd") == 0) {
CHECK_FOR_REQUIRED_ARGUMENTS(1);
xwl_add_listen_fd (argc, argv, i);
return 2;
}
else if (strcmp(argv[i], "-wm") == 0) {
CHECK_FOR_REQUIRED_ARGUMENTS(1);
wm_fd = atoi(argv[i + 1]);
return 2;
}
else if (strcmp(argv[i], "-initfd") == 0) {
CHECK_FOR_REQUIRED_ARGUMENTS(1);
init_fd = atoi(argv[i + 1]);
return 2;
}
else if (strcmp(argv[i], "-shm") == 0) {
return 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 if (strcmp(argv[i], "-eglstream") == 0) {
return 1;
}
return 0;
}
static CARD32
add_client_fd(OsTimerPtr timer, CARD32 time, void *arg)
{
if (!AddClientOnOpenFD(wm_fd))
FatalError("Failed to add wm client\n");
TimerFree(timer);
return 0;
}
static void
listen_on_fds(void)
{
int i;
for (i = 0; i < listen_fd_count; i++)
ListenOnOpenFD(listen_fds[i], FALSE);
}
static void
wm_selection_callback(CallbackListPtr *p, void *data, void *arg)
{
SelectionInfoRec *info = arg;
struct xwl_screen *xwl_screen = data;
static const char atom_name[] = "WM_S0";
static Atom atom_wm_s0;
if (atom_wm_s0 == None)
atom_wm_s0 = MakeAtom(atom_name, strlen(atom_name), TRUE);
if (info->selection->selection != atom_wm_s0 ||
info->kind != SelectionSetOwner)
return;
listen_on_fds();
DeleteCallback(&SelectionCallback, wm_selection_callback, xwl_screen);
}
_X_NORETURN
static void _X_ATTRIBUTE_PRINTF(1, 0)
xwl_log_handler(const char *format, va_list args)
{
char msg[256];
vsnprintf(msg, sizeof msg, format, args);
FatalError("%s", msg);
}
static const ExtensionModule xwayland_extensions[] = {
#ifdef XF86VIDMODE
{ xwlVidModeExtensionInit, XF86VIDMODENAME, &noXFree86VidModeExtension },
#endif
};
void
InitOutput(ScreenInfo * screen_info, int argc, char **argv)
{
int depths[] = { 1, 4, 8, 15, 16, 24, 32 };
int bpp[] = { 1, 8, 8, 16, 16, 32, 32 };
int i;
for (i = 0; i < ARRAY_SIZE(depths); i++) {
screen_info->formats[i].depth = depths[i];
screen_info->formats[i].bitsPerPixel = bpp[i];
screen_info->formats[i].scanlinePad = BITMAP_SCANLINE_PAD;
}
screen_info->imageByteOrder = IMAGE_BYTE_ORDER;
screen_info->bitmapScanlineUnit = BITMAP_SCANLINE_UNIT;
screen_info->bitmapScanlinePad = BITMAP_SCANLINE_PAD;
screen_info->bitmapBitOrder = BITMAP_BIT_ORDER;
screen_info->numPixmapFormats = ARRAY_SIZE(depths);
xwayland: Don't load extension list more than once When running an Xwayland server from the command line, we end up resetting the server every time all of the clients connected to the server leave. This would be fine, except that xwayland makes the mistake of unconditionally calling LoadExtensionList(). This causes us to setup the glxExtension twice in a row which means that when we lose our last client on the second server generation, we end up trying to call the glx destructors twice in a row resulting in a segfault: (EE) (EE) Backtrace: (EE) 0: Xwayland (OsSigHandler+0x3b) [0x4982f9] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x70845bf] (EE) 2: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32897d) [0x1196e5bd] (EE) 3: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x328a45) [0x1196e745] (EE) 4: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32665f) [0x11969f7f] (EE) 5: Xwayland (__glXDRIscreenDestroy+0x30) [0x54686e] (EE) 6: Xwayland (glxCloseScreen+0x3f) [0x5473db] (EE) 7: Xwayland (glxCloseScreen+0x53) [0x5473ef] (EE) 8: Xwayland (dix_main+0x7b6) [0x44c8c9] (EE) 9: Xwayland (main+0x28) [0x61c503] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x72b1401] (EE) 11: Xwayland (_start+0x2a) [0x4208fa] (EE) 12: ? (?+0x2a) [0x2a] (EE) (EE) Segmentation fault at address 0x18 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) Easy reproduction recipe: - Start an Xwayland session with the default settings - Open a window - Close that window - Open another window - Close that window - Total annihilation occurs Signed-off-by: Lyude <lyude@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2017-05-30 22:39:49 +02:00
if (serverGeneration == 1)
LoadExtensionList(xwayland_extensions,
ARRAY_SIZE(xwayland_extensions), FALSE);
/* Cast away warning from missing printf annotation for
* wl_log_func_t. Wayland 1.5 will have the annotation, so we can
* remove the cast and require that when it's released. */
wl_log_set_handler_client((void *) xwl_log_handler);
if (AddScreen(xwl_screen_init, argc, argv) == -1) {
FatalError("Couldn't add screen\n");
}
xorgGlxCreateVendor();
LocalAccessScopeUser();
if (wm_fd >= 0 || init_fd >= 0) {
if (wm_fd >= 0)
TimerSet(NULL, 0, 1, add_client_fd, NULL);
if (init_fd >= 0)
ListenOnOpenFD(init_fd, FALSE);
AddCallback(&SelectionCallback, wm_selection_callback, NULL);
}
else if (listen_fd_count > 0) {
listen_on_fds();
}
}