2014-03-12 00:11:39 +01:00
|
|
|
/*
|
|
|
|
* 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>
|
|
|
|
|
2016-11-23 12:30:53 +01:00
|
|
|
#include <X11/Xatom.h>
|
2014-03-12 00:11:39 +01:00
|
|
|
#include <selection.h>
|
|
|
|
#include <micmap.h>
|
|
|
|
#include <misyncshm.h>
|
|
|
|
#include <compositeext.h>
|
2018-01-25 13:43:09 +01:00
|
|
|
#include <compint.h>
|
2014-03-12 00:11:39 +01:00
|
|
|
#include <glx_extinit.h>
|
2016-05-24 12:46:42 +02:00
|
|
|
#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>
|
2016-11-23 12:30:53 +01:00
|
|
|
#include <propertyst.h>
|
2014-03-12 00:11:39 +01:00
|
|
|
|
2019-12-16 17:07:02 +01:00
|
|
|
#include "xwayland.h"
|
2019-12-16 17:23:30 +01:00
|
|
|
#include "xwayland-glamor.h"
|
2019-12-17 17:07:58 +01:00
|
|
|
#include "xwayland-pixmap.h"
|
2019-12-16 17:07:02 +01:00
|
|
|
#include "xwayland-shm.h"
|
|
|
|
#include "xwayland-window-buffers.h"
|
2019-12-17 17:07:58 +01:00
|
|
|
#include "xwayland-window.h"
|
2019-12-16 17:07:02 +01:00
|
|
|
|
2016-02-10 09:35:39 +01:00
|
|
|
#ifdef XF86VIDMODE
|
|
|
|
#include <X11/extensions/xf86vmproto.h>
|
|
|
|
_X_EXPORT Bool noXFree86VidModeExtension;
|
|
|
|
#endif
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
void
|
|
|
|
ddxGiveUp(enum ExitCode error)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
OsVendorInit(void)
|
|
|
|
{
|
2016-07-08 21:17:05 +02:00
|
|
|
if (serverGeneration == 1)
|
|
|
|
ForceClockId(CLOCK_MONOTONIC);
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
OsVendorFatalError(const char *f, va_list args)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#if defined(DDXBEFORERESET)
|
|
|
|
void
|
|
|
|
ddxBeforeReset(void)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2019-02-22 00:22:57 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#if INPUTTHREAD
|
|
|
|
/** This function is called in Xserver/os/inputthread.c when starting
|
|
|
|
the input thread. */
|
|
|
|
void
|
|
|
|
ddxInputThreadInit(void)
|
|
|
|
{
|
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
#endif
|
|
|
|
|
2017-11-21 14:45:13 +01:00
|
|
|
_X_NORETURN
|
|
|
|
static void _X_ATTRIBUTE_PRINTF(1, 2)
|
|
|
|
xwl_give_up(const char *f, ...)
|
|
|
|
{
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
va_start(args, f);
|
|
|
|
VErrorFSigSafe(f, args);
|
|
|
|
va_end(args);
|
|
|
|
|
|
|
|
CloseWellKnownConnections();
|
|
|
|
OsCleanup(TRUE);
|
|
|
|
fflush(stderr);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
void
|
|
|
|
ddxUseMsg(void)
|
|
|
|
{
|
|
|
|
ErrorF("-rootless run rootless, requires wm support\n");
|
|
|
|
ErrorF("-wm fd create X client for wm on given fd\n");
|
2019-07-20 00:16:43 +02:00
|
|
|
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");
|
2019-06-19 09:19:24 +02:00
|
|
|
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");
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
2019-07-20 00:16:43 +02:00
|
|
|
static int init_fd = -1;
|
2018-10-23 20:33:24 +02:00
|
|
|
static int wm_fd = -1;
|
|
|
|
static int listen_fds[5] = { -1, -1, -1, -1, -1 };
|
2019-01-02 21:55:23 +01:00
|
|
|
static int listen_fd_count = 0;
|
2018-10-23 20:33:24 +02:00
|
|
|
|
2019-06-19 09:19:24 +02:00
|
|
|
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]);
|
|
|
|
}
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
int
|
|
|
|
ddxProcessArgument(int argc, char *argv[], int i)
|
|
|
|
{
|
|
|
|
if (strcmp(argv[i], "-rootless") == 0) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
else if (strcmp(argv[i], "-listen") == 0) {
|
2018-10-23 20:33:24 +02:00
|
|
|
CHECK_FOR_REQUIRED_ARGUMENTS(1);
|
|
|
|
|
2019-06-18 10:41:02 +02:00
|
|
|
/* Not an FD */
|
|
|
|
if (!isdigit(*argv[i + 1]))
|
|
|
|
return 0;
|
|
|
|
|
2019-06-19 09:19:24 +02:00
|
|
|
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);
|
2018-10-23 20:33:24 +02:00
|
|
|
|
2019-06-19 09:19:24 +02:00
|
|
|
xwl_add_listen_fd (argc, argv, i);
|
2014-03-12 00:11:39 +01:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
else if (strcmp(argv[i], "-wm") == 0) {
|
2018-10-23 20:33:24 +02:00
|
|
|
CHECK_FOR_REQUIRED_ARGUMENTS(1);
|
|
|
|
wm_fd = atoi(argv[i + 1]);
|
2014-03-12 00:11:39 +01:00
|
|
|
return 2;
|
|
|
|
}
|
2019-07-20 00:16:43 +02:00
|
|
|
else if (strcmp(argv[i], "-initfd") == 0) {
|
|
|
|
CHECK_FOR_REQUIRED_ARGUMENTS(1);
|
|
|
|
init_fd = atoi(argv[i + 1]);
|
|
|
|
return 2;
|
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
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;
|
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-08-29 22:45:12 +02:00
|
|
|
static DevPrivateKeyRec xwl_client_private_key;
|
2014-03-12 00:11:39 +01:00
|
|
|
static DevPrivateKeyRec xwl_screen_private_key;
|
|
|
|
|
2019-08-29 22:45:12 +02:00
|
|
|
struct xwl_client *
|
|
|
|
xwl_client_get(ClientPtr client)
|
|
|
|
{
|
|
|
|
return dixLookupPrivate(&client->devPrivates, &xwl_client_private_key);
|
|
|
|
}
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
struct xwl_screen *
|
|
|
|
xwl_screen_get(ScreenPtr screen)
|
|
|
|
{
|
|
|
|
return dixLookupPrivate(&screen->devPrivates, &xwl_screen_private_key);
|
|
|
|
}
|
|
|
|
|
2019-06-26 16:46:54 +02:00
|
|
|
static Bool
|
|
|
|
xwl_screen_has_viewport_support(struct xwl_screen *xwl_screen)
|
|
|
|
{
|
|
|
|
return wl_compositor_get_version(xwl_screen->compositor) >=
|
|
|
|
WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION &&
|
|
|
|
xwl_screen->viewporter != NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
Bool
|
|
|
|
xwl_screen_has_resolution_change_emulation(struct xwl_screen *xwl_screen)
|
|
|
|
{
|
|
|
|
/* Resolution change emulation is only supported in rootless mode and
|
|
|
|
* it requires viewport support.
|
|
|
|
*/
|
|
|
|
return xwl_screen->rootless && xwl_screen_has_viewport_support(xwl_screen);
|
|
|
|
}
|
|
|
|
|
2019-07-02 11:55:26 +02:00
|
|
|
/* Return the output @ 0x0, falling back to the first output in the list */
|
|
|
|
struct xwl_output *
|
|
|
|
xwl_screen_get_first_output(struct xwl_screen *xwl_screen)
|
|
|
|
{
|
|
|
|
struct xwl_output *xwl_output;
|
|
|
|
|
|
|
|
xorg_list_for_each_entry(xwl_output, &xwl_screen->output_list, link) {
|
|
|
|
if (xwl_output->x == 0 && xwl_output->y == 0)
|
|
|
|
return xwl_output;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (xorg_list_is_empty(&xwl_screen->output_list))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return xorg_list_first_entry(&xwl_screen->output_list, struct xwl_output, link);
|
|
|
|
}
|
|
|
|
|
2016-11-23 12:30:53 +01:00
|
|
|
static void
|
|
|
|
xwl_property_callback(CallbackListPtr *pcbl, void *closure,
|
|
|
|
void *calldata)
|
|
|
|
{
|
|
|
|
ScreenPtr screen = closure;
|
|
|
|
PropertyStateRec *rec = calldata;
|
|
|
|
struct xwl_screen *xwl_screen;
|
|
|
|
struct xwl_window *xwl_window;
|
|
|
|
|
|
|
|
if (rec->win->drawable.pScreen != screen)
|
|
|
|
return;
|
|
|
|
|
2018-04-18 16:02:02 +02:00
|
|
|
xwl_window = xwl_window_get(rec->win);
|
2016-11-23 12:30:53 +01:00
|
|
|
if (!xwl_window)
|
|
|
|
return;
|
|
|
|
|
|
|
|
xwl_screen = xwl_screen_get(screen);
|
|
|
|
|
|
|
|
if (rec->prop->propertyName == xwl_screen->allow_commits_prop)
|
2019-12-17 15:07:07 +01:00
|
|
|
xwl_window_update_property(xwl_window, rec);
|
2016-11-23 12:30:53 +01:00
|
|
|
}
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
static Bool
|
|
|
|
xwl_close_screen(ScreenPtr screen)
|
|
|
|
{
|
|
|
|
struct xwl_screen *xwl_screen = xwl_screen_get(screen);
|
|
|
|
struct xwl_output *xwl_output, *next_xwl_output;
|
|
|
|
struct xwl_seat *xwl_seat, *next_xwl_seat;
|
|
|
|
|
2016-11-23 12:30:53 +01:00
|
|
|
DeleteCallback(&PropertyStateCallback, xwl_property_callback, screen);
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
xorg_list_for_each_entry_safe(xwl_output, next_xwl_output,
|
|
|
|
&xwl_screen->output_list, link)
|
|
|
|
xwl_output_destroy(xwl_output);
|
|
|
|
|
|
|
|
xorg_list_for_each_entry_safe(xwl_seat, next_xwl_seat,
|
|
|
|
&xwl_screen->seat_list, link)
|
|
|
|
xwl_seat_destroy(xwl_seat);
|
|
|
|
|
2016-01-16 02:29:37 +01:00
|
|
|
xwl_screen_release_tablet_manager(xwl_screen);
|
|
|
|
|
2015-11-24 02:36:53 +01:00
|
|
|
RemoveNotifyFd(xwl_screen->wayland_fd);
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
wl_display_disconnect(xwl_screen->display);
|
|
|
|
|
|
|
|
screen->CloseScreen = xwl_screen->CloseScreen;
|
|
|
|
free(xwl_screen);
|
|
|
|
|
|
|
|
return screen->CloseScreen(screen);
|
|
|
|
}
|
|
|
|
|
2016-09-13 09:17:07 +02:00
|
|
|
static struct xwl_seat *
|
|
|
|
xwl_screen_get_default_seat(struct xwl_screen *xwl_screen)
|
|
|
|
{
|
xwayland: Don't process cursor warping without an xwl_seat
Unfortunately, on my machine Xwayland immediately crashes when I try to
start it. gdb backtrace:
#0 0x00007ffff74f0e79 in wl_proxy_marshal () from target:/lib64/libwayland-client.so.0
#1 0x0000000000413172 in zwp_confined_pointer_v1_destroy (zwp_confined_pointer_v1=0x700000000)
at hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612
#2 0x0000000000418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839
#3 0x0000000000418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849
#4 0x0000000000410d97 in xwl_cursor_confined_to (device=0xa5a000, screen=0x8b9d80, window=0x9bdb70)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328
#5 0x00000000004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70, generateEvents=1,
confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900
#6 0x00000000004a94b7 in ScreenRestructured (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/dix/events.c:1387
#7 0x0000000000502386 in RRScreenSizeNotify (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/randr/rrscreen.c:160
#8 0x000000000041a83c in update_screen_size (xwl_output=0x8e7670, width=3840, height=2160)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203
#9 0x000000000041a9f0 in apply_output_change (xwl_output=0x8e7670)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252
#10 0x000000000041aaeb in xdg_output_handle_done (data=0x8e7670, xdg_output=0x8e7580)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307
#11 0x00007ffff50e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x00007ffff50e968f in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>,
avalue=<optimized out>) at ../src/x86/ffi64.c:525
#13 0x00007ffff74f3d8b in wl_closure_invoke () from target:/lib64/libwayland-client.so.0
#14 0x00007ffff74f0928 in dispatch_event.isra () from target:/lib64/libwayland-client.so.0
#15 0x00007ffff74f1be4 in wl_display_dispatch_queue_pending () from target:/lib64/libwayland-client.so.0
#16 0x00007ffff74f200b in wl_display_roundtrip_queue () from target:/lib64/libwayland-client.so.0
#17 0x0000000000418cad in InitInput (argc=12, argv=0x7fffffffd9c8)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867
#18 0x00000000004a20e3 in dix_main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/main.c:250
#19 0x0000000000420cb2 in main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/stubmain.c:34
This appears to be the result of xwl_cursor_confined_to() and
xwl_screen_get_default_seat(). While not against protocol, mutter ends
up sending xdg_output before wl_seat. xwl_screen_get_default_seat()
makes the naïve assumption that we always have a valid seat, we end up
returning a pointer to the empty list itself instead of an actual seat
and causing ourselves to segfault.
So, actually return NULL in xwl_screen_get_default_seat() if the seat
list is empty, and skip any pointer confinement processing in
xwl_cursor_confined_to() when we don't have a seat setup yet.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
2018-02-06 18:41:47 +01:00
|
|
|
if (xorg_list_is_empty(&xwl_screen->seat_list))
|
|
|
|
return NULL;
|
|
|
|
|
2016-09-13 09:17:07 +02:00
|
|
|
return container_of(xwl_screen->seat_list.prev,
|
|
|
|
struct xwl_seat,
|
|
|
|
link);
|
|
|
|
}
|
|
|
|
|
2016-09-13 09:17:08 +02:00
|
|
|
static void
|
|
|
|
xwl_cursor_warped_to(DeviceIntPtr device,
|
|
|
|
ScreenPtr screen,
|
|
|
|
ClientPtr client,
|
|
|
|
WindowPtr window,
|
|
|
|
SpritePtr sprite,
|
|
|
|
int x, int y)
|
|
|
|
{
|
|
|
|
struct xwl_screen *xwl_screen = xwl_screen_get(screen);
|
|
|
|
struct xwl_seat *xwl_seat = device->public.devicePrivate;
|
|
|
|
struct xwl_window *xwl_window;
|
2017-05-28 15:56:17 +02:00
|
|
|
WindowPtr focus;
|
2016-09-13 09:17:08 +02:00
|
|
|
|
|
|
|
if (!xwl_seat)
|
|
|
|
xwl_seat = xwl_screen_get_default_seat(xwl_screen);
|
|
|
|
|
xwayland: Don't crash on WarpPointer(dest_w = None)
Turns out that's legal, and xts exercises it, and we crash:
Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
122 return (char *) (*privates) + key->offset;
(gdb) bt
#0 dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
#1 dixLookupPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:166
#2 xwl_window_of_top (window=0x0) at xwayland.c:128
#3 xwl_cursor_warped_to (device=<optimized out>, screen=0x268b6e0, client=<optimized out>, window=0x0, sprite=0x300bb30,
x=2400, y=1350) at xwayland.c:292
#4 0x00000000005622ec in ProcWarpPointer (client=0x32755d0) at events.c:3618
In this case, x/y are the screen-space coordinates where the pointer
ends up, and we need to look up the (X) window there.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
2018-04-12 23:24:08 +02:00
|
|
|
if (!window)
|
|
|
|
window = XYToWindow(sprite, x, y);
|
|
|
|
|
2018-04-18 16:02:02 +02:00
|
|
|
xwl_window = xwl_window_from_window(window);
|
2017-05-28 15:56:17 +02:00
|
|
|
if (!xwl_window && xwl_seat->focus_window) {
|
|
|
|
focus = xwl_seat->focus_window->window;
|
|
|
|
|
|
|
|
/* Warps on non wl_surface backed Windows are only allowed
|
|
|
|
* as long as the pointer stays within the focus window.
|
|
|
|
*/
|
|
|
|
if (x >= focus->drawable.x &&
|
|
|
|
y >= focus->drawable.y &&
|
|
|
|
x < focus->drawable.x + focus->drawable.width &&
|
|
|
|
y < focus->drawable.y + focus->drawable.height) {
|
|
|
|
if (!window) {
|
|
|
|
DebugF("Warp relative to pointer, assuming pointer focus\n");
|
|
|
|
xwl_window = xwl_seat->focus_window;
|
|
|
|
} else if (window == screen->root) {
|
|
|
|
DebugF("Warp on root window, assuming pointer focus\n");
|
|
|
|
xwl_window = xwl_seat->focus_window;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-09-13 09:17:08 +02:00
|
|
|
if (!xwl_window)
|
|
|
|
return;
|
|
|
|
|
|
|
|
xwl_seat_emulate_pointer_warp(xwl_seat, xwl_window, sprite, x, y);
|
|
|
|
}
|
|
|
|
|
2016-09-13 09:17:07 +02:00
|
|
|
static void
|
|
|
|
xwl_cursor_confined_to(DeviceIntPtr device,
|
|
|
|
ScreenPtr screen,
|
|
|
|
WindowPtr window)
|
|
|
|
{
|
|
|
|
struct xwl_screen *xwl_screen = xwl_screen_get(screen);
|
|
|
|
struct xwl_seat *xwl_seat = device->public.devicePrivate;
|
|
|
|
struct xwl_window *xwl_window;
|
|
|
|
|
|
|
|
if (!xwl_seat)
|
|
|
|
xwl_seat = xwl_screen_get_default_seat(xwl_screen);
|
|
|
|
|
xwayland: Don't process cursor warping without an xwl_seat
Unfortunately, on my machine Xwayland immediately crashes when I try to
start it. gdb backtrace:
#0 0x00007ffff74f0e79 in wl_proxy_marshal () from target:/lib64/libwayland-client.so.0
#1 0x0000000000413172 in zwp_confined_pointer_v1_destroy (zwp_confined_pointer_v1=0x700000000)
at hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612
#2 0x0000000000418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839
#3 0x0000000000418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849
#4 0x0000000000410d97 in xwl_cursor_confined_to (device=0xa5a000, screen=0x8b9d80, window=0x9bdb70)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328
#5 0x00000000004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70, generateEvents=1,
confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900
#6 0x00000000004a94b7 in ScreenRestructured (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/dix/events.c:1387
#7 0x0000000000502386 in RRScreenSizeNotify (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/randr/rrscreen.c:160
#8 0x000000000041a83c in update_screen_size (xwl_output=0x8e7670, width=3840, height=2160)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203
#9 0x000000000041a9f0 in apply_output_change (xwl_output=0x8e7670)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252
#10 0x000000000041aaeb in xdg_output_handle_done (data=0x8e7670, xdg_output=0x8e7580)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307
#11 0x00007ffff50e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x00007ffff50e968f in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>,
avalue=<optimized out>) at ../src/x86/ffi64.c:525
#13 0x00007ffff74f3d8b in wl_closure_invoke () from target:/lib64/libwayland-client.so.0
#14 0x00007ffff74f0928 in dispatch_event.isra () from target:/lib64/libwayland-client.so.0
#15 0x00007ffff74f1be4 in wl_display_dispatch_queue_pending () from target:/lib64/libwayland-client.so.0
#16 0x00007ffff74f200b in wl_display_roundtrip_queue () from target:/lib64/libwayland-client.so.0
#17 0x0000000000418cad in InitInput (argc=12, argv=0x7fffffffd9c8)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867
#18 0x00000000004a20e3 in dix_main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/main.c:250
#19 0x0000000000420cb2 in main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/stubmain.c:34
This appears to be the result of xwl_cursor_confined_to() and
xwl_screen_get_default_seat(). While not against protocol, mutter ends
up sending xdg_output before wl_seat. xwl_screen_get_default_seat()
makes the naïve assumption that we always have a valid seat, we end up
returning a pointer to the empty list itself instead of an actual seat
and causing ourselves to segfault.
So, actually return NULL in xwl_screen_get_default_seat() if the seat
list is empty, and skip any pointer confinement processing in
xwl_cursor_confined_to() when we don't have a seat setup yet.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
2018-02-06 18:41:47 +01:00
|
|
|
/* xwl_seat hasn't been setup yet, don't do anything just yet */
|
|
|
|
if (!xwl_seat)
|
|
|
|
return;
|
|
|
|
|
2016-09-13 09:17:07 +02:00
|
|
|
if (window == screen->root) {
|
|
|
|
xwl_seat_unconfine_pointer(xwl_seat);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-04-18 16:02:02 +02:00
|
|
|
xwl_window = xwl_window_from_window(window);
|
2017-05-28 15:56:18 +02:00
|
|
|
if (!xwl_window && xwl_seat->focus_window) {
|
|
|
|
/* Allow confining on InputOnly windows, but only if the geometry
|
|
|
|
* is the same than the focus window.
|
|
|
|
*/
|
|
|
|
if (window->drawable.class == InputOnly) {
|
|
|
|
DebugF("Confine on InputOnly window, assuming pointer focus\n");
|
|
|
|
xwl_window = xwl_seat->focus_window;
|
|
|
|
}
|
|
|
|
}
|
2016-09-13 09:17:07 +02:00
|
|
|
if (!xwl_window)
|
|
|
|
return;
|
|
|
|
|
|
|
|
xwl_seat_confine_pointer(xwl_seat, xwl_window);
|
|
|
|
}
|
|
|
|
|
2019-07-02 11:55:26 +02:00
|
|
|
void
|
|
|
|
xwl_screen_check_resolution_change_emulation(struct xwl_screen *xwl_screen)
|
|
|
|
{
|
|
|
|
struct xwl_window *xwl_window;
|
|
|
|
|
|
|
|
xorg_list_for_each_entry(xwl_window, &xwl_screen->window_list, link_window)
|
|
|
|
xwl_window_check_resolution_change_emulation(xwl_window);
|
|
|
|
}
|
|
|
|
|
2016-11-24 10:45:25 +01:00
|
|
|
static void
|
|
|
|
xwl_screen_post_damage(struct xwl_screen *xwl_screen)
|
|
|
|
{
|
|
|
|
struct xwl_window *xwl_window, *next_xwl_window;
|
|
|
|
|
|
|
|
xorg_list_for_each_entry_safe(xwl_window, next_xwl_window,
|
|
|
|
&xwl_screen->damage_window_list, link_damage) {
|
|
|
|
/* If we're waiting on a frame callback from the server,
|
|
|
|
* don't attach a new buffer. */
|
|
|
|
if (xwl_window->frame_callback)
|
|
|
|
continue;
|
|
|
|
|
2016-11-23 12:30:53 +01:00
|
|
|
if (!xwl_window->allow_commits)
|
|
|
|
continue;
|
|
|
|
|
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
|
|
|
#ifdef XWL_HAS_GLAMOR
|
2018-06-05 19:38:43 +02:00
|
|
|
if (xwl_screen->glamor && !xwl_glamor_allow_commits(xwl_window))
|
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
|
|
|
continue;
|
|
|
|
#endif
|
|
|
|
|
2016-11-24 10:45:25 +01:00
|
|
|
xwl_window_post_damage(xwl_window);
|
2014-06-30 19:53:50 +02:00
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
registry_global(void *data, struct wl_registry *registry, uint32_t id,
|
|
|
|
const char *interface, uint32_t version)
|
|
|
|
{
|
|
|
|
struct xwl_screen *xwl_screen = data;
|
|
|
|
|
|
|
|
if (strcmp(interface, "wl_compositor") == 0) {
|
2019-07-02 12:03:12 +02:00
|
|
|
uint32_t request_version = 1;
|
|
|
|
|
|
|
|
if (version >= WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION)
|
|
|
|
request_version = WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION;
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
xwl_screen->compositor =
|
2019-07-02 12:03:12 +02:00
|
|
|
wl_registry_bind(registry, id, &wl_compositor_interface, request_version);
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
else if (strcmp(interface, "wl_shm") == 0) {
|
|
|
|
xwl_screen->shm = wl_registry_bind(registry, id, &wl_shm_interface, 1);
|
|
|
|
}
|
|
|
|
else if (strcmp(interface, "wl_shell") == 0) {
|
|
|
|
xwl_screen->shell =
|
|
|
|
wl_registry_bind(registry, id, &wl_shell_interface, 1);
|
|
|
|
}
|
|
|
|
else if (strcmp(interface, "wl_output") == 0 && version >= 2) {
|
2015-11-27 14:27:46 +01:00
|
|
|
if (xwl_output_create(xwl_screen, id))
|
|
|
|
xwl_screen->expecting_event++;
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
2017-09-07 17:43:16 +02:00
|
|
|
else if (strcmp(interface, "zxdg_output_manager_v1") == 0) {
|
2019-09-02 21:42:17 +02:00
|
|
|
/* We support xdg-output from version 1 to version 3 */
|
|
|
|
version = min(version, 3);
|
2017-09-07 17:43:16 +02:00
|
|
|
xwl_screen->xdg_output_manager =
|
2019-09-02 21:42:17 +02:00
|
|
|
wl_registry_bind(registry, id, &zxdg_output_manager_v1_interface, version);
|
2017-09-07 17:43:16 +02:00
|
|
|
xwl_screen_init_xdg_output(xwl_screen);
|
|
|
|
}
|
2018-01-22 22:02:32 +01:00
|
|
|
else if (strcmp(interface, "wp_viewporter") == 0) {
|
|
|
|
xwl_screen->viewporter = wl_registry_bind(registry, id, &wp_viewporter_interface, 1);
|
|
|
|
}
|
2018-04-20 20:38:04 +02:00
|
|
|
#ifdef XWL_HAS_GLAMOR
|
2018-04-20 20:38:03 +02:00
|
|
|
else if (xwl_screen->glamor) {
|
|
|
|
xwl_glamor_init_wl_registry(xwl_screen, registry, id, interface,
|
|
|
|
version);
|
2014-06-16 20:34:55 +02:00
|
|
|
}
|
|
|
|
#endif
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
global_remove(void *data, struct wl_registry *registry, uint32_t name)
|
|
|
|
{
|
2015-05-16 07:38:28 +02:00
|
|
|
struct xwl_screen *xwl_screen = data;
|
|
|
|
struct xwl_output *xwl_output, *tmp_xwl_output;
|
|
|
|
|
|
|
|
xorg_list_for_each_entry_safe(xwl_output, tmp_xwl_output,
|
|
|
|
&xwl_screen->output_list, link) {
|
|
|
|
if (xwl_output->server_output_id == name) {
|
2016-08-08 17:57:57 +02:00
|
|
|
xwl_output_remove(xwl_output);
|
2015-05-16 07:38:28 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct wl_registry_listener registry_listener = {
|
|
|
|
registry_global,
|
|
|
|
global_remove
|
|
|
|
};
|
|
|
|
|
|
|
|
static void
|
2016-03-09 11:17:27 +01:00
|
|
|
xwl_read_events (struct xwl_screen *xwl_screen)
|
2014-03-12 00:11:39 +01:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
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
|
|
|
if (xwl_screen->wait_flush)
|
|
|
|
return;
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
ret = wl_display_read_events(xwl_screen->display);
|
|
|
|
if (ret == -1)
|
2017-11-21 14:45:13 +01:00
|
|
|
xwl_give_up("failed to read Wayland events: %s\n", strerror(errno));
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
xwl_screen->prepare_read = 0;
|
|
|
|
|
|
|
|
ret = wl_display_dispatch_pending(xwl_screen->display);
|
|
|
|
if (ret == -1)
|
2017-11-21 14:45:13 +01:00
|
|
|
xwl_give_up("failed to dispatch Wayland events: %s\n", strerror(errno));
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
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
|
|
|
static int
|
|
|
|
xwl_display_pollout (struct xwl_screen *xwl_screen, int timeout)
|
|
|
|
{
|
|
|
|
struct pollfd poll_fd;
|
|
|
|
|
|
|
|
poll_fd.fd = wl_display_get_fd(xwl_screen->display);
|
|
|
|
poll_fd.events = POLLOUT;
|
|
|
|
|
|
|
|
return xserver_poll(&poll_fd, 1, timeout);
|
|
|
|
}
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
static void
|
2016-03-09 11:17:27 +01:00
|
|
|
xwl_dispatch_events (struct xwl_screen *xwl_screen)
|
2014-03-12 00:11:39 +01:00
|
|
|
{
|
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
|
|
|
int ret = 0;
|
|
|
|
int ready;
|
|
|
|
|
|
|
|
if (xwl_screen->wait_flush)
|
|
|
|
goto pollout;
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
while (xwl_screen->prepare_read == 0 &&
|
|
|
|
wl_display_prepare_read(xwl_screen->display) == -1) {
|
|
|
|
ret = wl_display_dispatch_pending(xwl_screen->display);
|
|
|
|
if (ret == -1)
|
2017-11-21 14:45:13 +01:00
|
|
|
xwl_give_up("failed to dispatch Wayland events: %s\n",
|
2014-03-12 00:11:39 +01:00
|
|
|
strerror(errno));
|
|
|
|
}
|
|
|
|
|
|
|
|
xwl_screen->prepare_read = 1;
|
|
|
|
|
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
|
|
|
pollout:
|
|
|
|
ready = xwl_display_pollout(xwl_screen, 5);
|
|
|
|
if (ready == -1 && errno != EINTR)
|
2017-11-21 14:45:13 +01:00
|
|
|
xwl_give_up("error polling on XWayland fd: %s\n", strerror(errno));
|
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
|
|
|
|
|
|
|
if (ready > 0)
|
|
|
|
ret = wl_display_flush(xwl_screen->display);
|
|
|
|
|
|
|
|
if (ret == -1 && errno != EAGAIN)
|
2017-11-21 14:45:13 +01:00
|
|
|
xwl_give_up("failed to write to XWayland fd: %s\n", strerror(errno));
|
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
|
|
|
|
|
|
|
xwl_screen->wait_flush = (ready == 0 || ready == -1 || ret == -1);
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
2016-03-09 11:17:27 +01:00
|
|
|
static void
|
|
|
|
socket_handler(int fd, int ready, void *data)
|
|
|
|
{
|
|
|
|
struct xwl_screen *xwl_screen = data;
|
|
|
|
|
|
|
|
xwl_read_events (xwl_screen);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2015-09-02 03:51:14 +02:00
|
|
|
wakeup_handler(void *data, int err)
|
2016-03-09 11:17:27 +01:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2015-09-02 03:51:14 +02:00
|
|
|
block_handler(void *data, void *timeout)
|
2016-03-09 11:17:27 +01:00
|
|
|
{
|
|
|
|
struct xwl_screen *xwl_screen = data;
|
|
|
|
|
|
|
|
xwl_screen_post_damage(xwl_screen);
|
|
|
|
xwl_dispatch_events (xwl_screen);
|
|
|
|
}
|
|
|
|
|
2016-03-09 10:33:50 +01:00
|
|
|
void
|
|
|
|
xwl_sync_events (struct xwl_screen *xwl_screen)
|
|
|
|
{
|
|
|
|
xwl_dispatch_events (xwl_screen);
|
|
|
|
xwl_read_events (xwl_screen);
|
|
|
|
}
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
static CARD32
|
|
|
|
add_client_fd(OsTimerPtr timer, CARD32 time, void *arg)
|
|
|
|
{
|
2018-10-23 20:33:24 +02:00
|
|
|
if (!AddClientOnOpenFD(wm_fd))
|
2014-03-12 00:11:39 +01:00
|
|
|
FatalError("Failed to add wm client\n");
|
|
|
|
|
|
|
|
TimerFree(timer);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2018-10-23 20:33:24 +02:00
|
|
|
listen_on_fds(void)
|
2014-03-12 00:11:39 +01:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2018-10-23 20:33:24 +02:00
|
|
|
for (i = 0; i < listen_fd_count; i++)
|
|
|
|
ListenOnOpenFD(listen_fds[i], FALSE);
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
2018-10-23 20:33:24 +02:00
|
|
|
listen_on_fds();
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
DeleteCallback(&SelectionCallback, wm_selection_callback, xwl_screen);
|
|
|
|
}
|
|
|
|
|
|
|
|
static Bool
|
|
|
|
xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
|
|
|
|
{
|
2016-11-23 12:30:53 +01:00
|
|
|
static const char allow_commits[] = "_XWAYLAND_ALLOW_COMMITS";
|
2014-03-12 00:11:39 +01:00
|
|
|
struct xwl_screen *xwl_screen;
|
|
|
|
Pixel red_mask, blue_mask, green_mask;
|
|
|
|
int ret, bpc, green_bpc, i;
|
2019-07-31 11:14:37 +02:00
|
|
|
#ifdef 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 20:38:05 +02:00
|
|
|
Bool use_eglstreams = FALSE;
|
2019-07-31 11:14:37 +02:00
|
|
|
#endif
|
2014-03-12 00:11:39 +01:00
|
|
|
|
2016-11-23 08:54:27 +01:00
|
|
|
xwl_screen = calloc(1, sizeof *xwl_screen);
|
2014-03-12 00:11:39 +01:00
|
|
|
if (xwl_screen == NULL)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
if (!dixRegisterPrivateKey(&xwl_screen_private_key, PRIVATE_SCREEN, 0))
|
|
|
|
return FALSE;
|
2019-12-17 17:07:58 +01:00
|
|
|
if (!xwl_pixmap_init())
|
2019-10-30 13:17:34 +01:00
|
|
|
return FALSE;
|
2019-12-17 15:07:07 +01:00
|
|
|
if (!xwl_window_init())
|
2019-01-07 15:20:05 +01:00
|
|
|
return FALSE;
|
2019-08-29 22:45:12 +02:00
|
|
|
/* There are no easy to use new / delete client hooks, we could use a
|
|
|
|
* ClientStateCallback, but it is easier to let the dix code manage the
|
|
|
|
* memory for us. This will zero fill the initial xwl_client data.
|
|
|
|
*/
|
|
|
|
if (!dixRegisterPrivateKey(&xwl_client_private_key, PRIVATE_CLIENT,
|
|
|
|
sizeof(struct xwl_client)))
|
|
|
|
return FALSE;
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
dixSetPrivate(&pScreen->devPrivates, &xwl_screen_private_key, xwl_screen);
|
|
|
|
xwl_screen->screen = pScreen;
|
|
|
|
|
2018-04-20 20:38:04 +02:00
|
|
|
#ifdef XWL_HAS_GLAMOR
|
2014-06-16 20:34:55 +02:00
|
|
|
xwl_screen->glamor = 1;
|
|
|
|
#endif
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
for (i = 1; i < argc; i++) {
|
|
|
|
if (strcmp(argv[i], "-rootless") == 0) {
|
|
|
|
xwl_screen->rootless = 1;
|
|
|
|
}
|
2014-06-16 20:34:55 +02:00
|
|
|
else if (strcmp(argv[i], "-shm") == 0) {
|
|
|
|
xwl_screen->glamor = 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
|
|
|
else if (strcmp(argv[i], "-eglstream") == 0) {
|
2018-06-05 19:37:54 +02:00
|
|
|
#ifdef XWL_HAS_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
|
|
|
use_eglstreams = TRUE;
|
2018-06-05 19:37:54 +02:00
|
|
|
#else
|
|
|
|
ErrorF("xwayland glamor: this build does not have EGLStream support\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
|
|
|
#endif
|
2018-06-05 19:37:54 +02:00
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|
|
|
|
|
2018-04-20 20:38:04 +02:00
|
|
|
#ifdef XWL_HAS_GLAMOR
|
2018-06-05 19:38:42 +02:00
|
|
|
if (xwl_screen->glamor)
|
|
|
|
xwl_glamor_init_backends(xwl_screen, use_eglstreams);
|
2018-04-20 20:38:04 +02:00
|
|
|
#endif
|
2018-04-20 20:38:03 +02:00
|
|
|
|
dix: Add hybrid full-size/empty-clip mode to SetRootClip
216bdbc735 removed the SetRootClip call in the XWayland output-hotplug
handler when running rootless (e.g. as a part of Weston/Mutter), since
the root window has no storage, so generating exposures will result in
writes to invalid memory.
Unfortunately, preventing the segfault also breaks sprite confinement.
SetRootClip updates winSize and borderSize for the root window, which
when combined with RRScreenSizeChanged calling ScreenRestructured,
generates a new sprite-confinment area to update it to the whole screen.
Removing this call results in the window geometry being reported
correctly, but winSize/borderSize never changing from their values at
startup, i.e. out of sync with the root window geometry / screen
information in the connection info / XRandR.
This patch introduces a hybrid mode, where we update winSize and
borderSize for the root window, enabling sprite confinement to work
correctly, but keep the clip emptied so exposures are never generated.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
2016-02-12 17:36:59 +01:00
|
|
|
/* In rootless mode, we don't have any screen storage, and the only
|
|
|
|
* rendering should be to redirected mode. */
|
|
|
|
if (xwl_screen->rootless)
|
|
|
|
xwl_screen->root_clip_mode = ROOT_CLIP_INPUT_ONLY;
|
|
|
|
else
|
|
|
|
xwl_screen->root_clip_mode = ROOT_CLIP_FULL;
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
xorg_list_init(&xwl_screen->output_list);
|
|
|
|
xorg_list_init(&xwl_screen->seat_list);
|
|
|
|
xorg_list_init(&xwl_screen->damage_window_list);
|
2019-07-02 11:55:26 +02:00
|
|
|
xorg_list_init(&xwl_screen->window_list);
|
2014-03-12 00:11:39 +01:00
|
|
|
xwl_screen->depth = 24;
|
|
|
|
|
|
|
|
xwl_screen->display = wl_display_connect(NULL);
|
|
|
|
if (xwl_screen->display == NULL) {
|
|
|
|
ErrorF("could not connect to wayland server\n");
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!xwl_screen_init_output(xwl_screen))
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
xwl_screen->expecting_event = 0;
|
|
|
|
xwl_screen->registry = wl_display_get_registry(xwl_screen->display);
|
|
|
|
wl_registry_add_listener(xwl_screen->registry,
|
|
|
|
®istry_listener, xwl_screen);
|
|
|
|
ret = wl_display_roundtrip(xwl_screen->display);
|
|
|
|
if (ret == -1) {
|
|
|
|
ErrorF("could not connect to wayland server\n");
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (xwl_screen->expecting_event > 0)
|
|
|
|
wl_display_roundtrip(xwl_screen->display);
|
|
|
|
|
|
|
|
bpc = xwl_screen->depth / 3;
|
|
|
|
green_bpc = xwl_screen->depth - 2 * bpc;
|
|
|
|
blue_mask = (1 << bpc) - 1;
|
|
|
|
green_mask = ((1 << green_bpc) - 1) << bpc;
|
|
|
|
red_mask = blue_mask << (green_bpc + bpc);
|
|
|
|
|
|
|
|
miSetVisualTypesAndMasks(xwl_screen->depth,
|
|
|
|
((1 << TrueColor) | (1 << DirectColor)),
|
|
|
|
green_bpc, TrueColor,
|
|
|
|
red_mask, green_mask, blue_mask);
|
|
|
|
|
|
|
|
miSetPixmapDepths();
|
|
|
|
|
|
|
|
ret = fbScreenInit(pScreen, NULL,
|
|
|
|
xwl_screen->width, xwl_screen->height,
|
|
|
|
96, 96, 0,
|
|
|
|
BitsPerPixel(xwl_screen->depth));
|
|
|
|
if (!ret)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
fbPictureInit(pScreen, 0, 0);
|
|
|
|
|
2014-04-08 18:19:13 +02:00
|
|
|
#ifdef HAVE_XSHMFENCE
|
2014-03-12 00:11:39 +01:00
|
|
|
if (!miSyncShmScreenInit(pScreen))
|
|
|
|
return FALSE;
|
2014-04-08 18:19:13 +02:00
|
|
|
#endif
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
xwl_screen->wayland_fd = wl_display_get_fd(xwl_screen->display);
|
2015-11-24 02:36:53 +01:00
|
|
|
SetNotifyFd(xwl_screen->wayland_fd, socket_handler, X_NOTIFY_READ, xwl_screen);
|
2014-03-12 00:11:39 +01:00
|
|
|
RegisterBlockAndWakeupHandlers(block_handler, wakeup_handler, xwl_screen);
|
|
|
|
|
|
|
|
pScreen->blackPixel = 0;
|
|
|
|
pScreen->whitePixel = 1;
|
|
|
|
|
|
|
|
ret = fbCreateDefColormap(pScreen);
|
|
|
|
|
|
|
|
if (!xwl_screen_init_cursor(xwl_screen))
|
|
|
|
return FALSE;
|
|
|
|
|
2018-04-20 20:38:04 +02:00
|
|
|
#ifdef XWL_HAS_GLAMOR
|
2018-06-05 19:38:43 +02:00
|
|
|
if (xwl_screen->glamor) {
|
|
|
|
xwl_glamor_select_backend(xwl_screen, use_eglstreams);
|
|
|
|
|
|
|
|
if (xwl_screen->egl_backend == NULL || !xwl_glamor_init(xwl_screen)) {
|
|
|
|
ErrorF("Failed to initialize glamor, falling back to sw\n");
|
|
|
|
xwl_screen->glamor = 0;
|
|
|
|
}
|
2014-06-16 20:34:55 +02:00
|
|
|
}
|
|
|
|
|
2018-03-13 16:00:57 +01:00
|
|
|
if (xwl_screen->glamor && xwl_screen->rootless)
|
|
|
|
xwl_screen->present = xwl_present_init(pScreen);
|
2018-04-16 09:39:09 +02:00
|
|
|
#endif
|
2018-03-13 16:00:57 +01:00
|
|
|
|
2014-06-16 20:34:55 +02:00
|
|
|
if (!xwl_screen->glamor) {
|
|
|
|
xwl_screen->CreateScreenResources = pScreen->CreateScreenResources;
|
|
|
|
pScreen->CreateScreenResources = xwl_shm_create_screen_resources;
|
|
|
|
pScreen->CreatePixmap = xwl_shm_create_pixmap;
|
|
|
|
pScreen->DestroyPixmap = xwl_shm_destroy_pixmap;
|
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
xwl_screen->RealizeWindow = pScreen->RealizeWindow;
|
|
|
|
pScreen->RealizeWindow = xwl_realize_window;
|
|
|
|
|
|
|
|
xwl_screen->UnrealizeWindow = pScreen->UnrealizeWindow;
|
|
|
|
pScreen->UnrealizeWindow = xwl_unrealize_window;
|
|
|
|
|
2018-05-04 03:07:31 +02:00
|
|
|
xwl_screen->DestroyWindow = pScreen->DestroyWindow;
|
|
|
|
pScreen->DestroyWindow = xwl_destroy_window;
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
xwl_screen->CloseScreen = pScreen->CloseScreen;
|
|
|
|
pScreen->CloseScreen = xwl_close_screen;
|
|
|
|
|
2019-07-02 11:55:26 +02:00
|
|
|
xwl_screen->ResizeWindow = pScreen->ResizeWindow;
|
|
|
|
pScreen->ResizeWindow = xwl_resize_window;
|
|
|
|
|
2019-01-07 15:33:35 +01:00
|
|
|
if (xwl_screen->rootless) {
|
|
|
|
xwl_screen->SetWindowPixmap = pScreen->SetWindowPixmap;
|
2019-12-17 15:07:07 +01:00
|
|
|
pScreen->SetWindowPixmap = xwl_window_set_window_pixmap;
|
2019-01-07 15:33:35 +01:00
|
|
|
}
|
|
|
|
|
2016-09-13 09:17:08 +02:00
|
|
|
pScreen->CursorWarpedTo = xwl_cursor_warped_to;
|
2016-09-13 09:17:07 +02:00
|
|
|
pScreen->CursorConfinedTo = xwl_cursor_confined_to;
|
|
|
|
|
2016-11-23 12:30:53 +01:00
|
|
|
xwl_screen->allow_commits_prop = MakeAtom(allow_commits,
|
|
|
|
strlen(allow_commits),
|
|
|
|
TRUE);
|
|
|
|
if (xwl_screen->allow_commits_prop == BAD_RESOURCE)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
AddCallback(&PropertyStateCallback, xwl_property_callback, pScreen);
|
|
|
|
|
2018-06-05 19:37:56 +02:00
|
|
|
wl_display_roundtrip(xwl_screen->display);
|
|
|
|
while (xwl_screen->expecting_event)
|
|
|
|
wl_display_roundtrip(xwl_screen->display);
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-10-31 00:26:28 +01:00
|
|
|
_X_NORETURN
|
2014-03-12 00:11:39 +01:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2014-04-08 18:17:51 +02:00
|
|
|
static const ExtensionModule xwayland_extensions[] = {
|
2016-02-10 09:35:39 +01:00
|
|
|
#ifdef XF86VIDMODE
|
|
|
|
{ xwlVidModeExtensionInit, XF86VIDMODENAME, &noXFree86VidModeExtension },
|
|
|
|
#endif
|
2014-03-12 00:11:39 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
2017-05-30 22:39:49 +02:00
|
|
|
if (serverGeneration == 1)
|
|
|
|
LoadExtensionList(xwayland_extensions,
|
|
|
|
ARRAY_SIZE(xwayland_extensions), FALSE);
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
/* 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");
|
|
|
|
}
|
2015-05-05 22:43:44 +02:00
|
|
|
|
2018-01-10 19:05:45 +01:00
|
|
|
xorgGlxCreateVendor();
|
|
|
|
|
2015-05-05 22:43:44 +02:00
|
|
|
LocalAccessScopeUser();
|
2018-10-23 21:07:48 +02:00
|
|
|
|
2019-07-20 00:16:43 +02:00
|
|
|
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);
|
2019-01-02 21:55:23 +01:00
|
|
|
AddCallback(&SelectionCallback, wm_selection_callback, NULL);
|
2019-07-20 00:16:43 +02:00
|
|
|
}
|
|
|
|
else if (listen_fd_count > 0) {
|
2019-01-02 21:55:23 +01:00
|
|
|
listen_on_fds();
|
2018-10-23 21:07:48 +02:00
|
|
|
}
|
2014-03-12 00:11:39 +01:00
|
|
|
}
|