2014-03-12 00:11:39 +01:00
|
|
|
/*
|
|
|
|
* Copyright © 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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef XWAYLAND_H
|
|
|
|
#define XWAYLAND_H
|
|
|
|
|
2018-04-20 20:38:04 +02:00
|
|
|
#include <xwayland-config.h>
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <errno.h>
|
|
|
|
|
|
|
|
#include <wayland-client.h>
|
|
|
|
|
|
|
|
#include <X11/X.h>
|
|
|
|
|
|
|
|
#include <fb.h>
|
|
|
|
#include <input.h>
|
|
|
|
#include <dix.h>
|
|
|
|
#include <randrstr.h>
|
|
|
|
#include <exevents.h>
|
|
|
|
|
2016-09-29 04:40:01 +02:00
|
|
|
#include "relative-pointer-unstable-v1-client-protocol.h"
|
2016-09-29 04:42:13 +02:00
|
|
|
#include "pointer-constraints-unstable-v1-client-protocol.h"
|
2016-11-04 19:58:04 +01:00
|
|
|
#include "tablet-unstable-v2-client-protocol.h"
|
2017-07-12 11:51:08 +02:00
|
|
|
#include "xwayland-keyboard-grab-unstable-v1-client-protocol.h"
|
2017-09-07 17:43:16 +02:00
|
|
|
#include "xdg-output-unstable-v1-client-protocol.h"
|
2018-02-28 02:19:43 +01:00
|
|
|
#include "linux-dmabuf-unstable-v1-client-protocol.h"
|
2016-09-29 04:40:01 +02:00
|
|
|
|
2018-02-28 02:19:44 +01:00
|
|
|
struct xwl_format {
|
|
|
|
uint32_t format;
|
|
|
|
int num_modifiers;
|
|
|
|
uint64_t *modifiers;
|
|
|
|
};
|
|
|
|
|
2018-04-20 20:38:03 +02:00
|
|
|
struct xwl_pixmap;
|
|
|
|
struct xwl_window;
|
2018-06-05 19:38:40 +02:00
|
|
|
struct xwl_screen;
|
|
|
|
|
|
|
|
struct xwl_egl_backend {
|
2018-06-05 19:38:43 +02:00
|
|
|
/* Set by the backend if available */
|
|
|
|
Bool is_available;
|
|
|
|
|
2018-06-05 19:38:40 +02:00
|
|
|
/* Called once for each interface in the global registry. Backends
|
2018-06-11 09:21:08 +02:00
|
|
|
* should use this to bind to any wayland interfaces they need.
|
2018-06-05 19:38:40 +02:00
|
|
|
*/
|
2018-06-05 19:38:43 +02:00
|
|
|
Bool (*init_wl_registry)(struct xwl_screen *xwl_screen,
|
2018-06-05 19:38:40 +02:00
|
|
|
struct wl_registry *wl_registry,
|
|
|
|
uint32_t id, const char *name,
|
|
|
|
uint32_t version);
|
|
|
|
|
2018-06-11 09:21:08 +02:00
|
|
|
/* Check that the required Wayland interfaces are available.
|
2018-06-05 19:38:41 +02:00
|
|
|
*/
|
|
|
|
Bool (*has_wl_interfaces)(struct xwl_screen *xwl_screen);
|
|
|
|
|
2018-06-05 19:38:40 +02:00
|
|
|
/* Called before glamor has been initialized. Backends should setup a
|
|
|
|
* valid, glamor compatible EGL context in this hook.
|
|
|
|
*/
|
|
|
|
Bool (*init_egl)(struct xwl_screen *xwl_screen);
|
|
|
|
|
|
|
|
/* Called after glamor has been initialized, and after all of the
|
|
|
|
* common Xwayland DDX hooks have been connected. Backends should use
|
|
|
|
* this to setup any required wraps around X server callbacks like
|
|
|
|
* CreatePixmap.
|
|
|
|
*/
|
|
|
|
Bool (*init_screen)(struct xwl_screen *xwl_screen);
|
|
|
|
|
|
|
|
/* Called by Xwayland to retrieve a pointer to a valid wl_buffer for
|
|
|
|
* the given window/pixmap combo so that damage to the pixmap may be
|
|
|
|
* displayed on-screen. Backends should use this to create a new
|
|
|
|
* wl_buffer for a currently buffer-less pixmap, or simply return the
|
|
|
|
* pixmap they've prepared beforehand.
|
|
|
|
*/
|
|
|
|
struct wl_buffer *(*get_wl_buffer_for_pixmap)(PixmapPtr pixmap,
|
|
|
|
Bool *created);
|
|
|
|
|
|
|
|
/* Called by Xwayland to perform any pre-wl_surface damage routines
|
|
|
|
* that are required by the backend. If your backend is poorly
|
|
|
|
* designed and lacks the ability to render directly to a surface,
|
|
|
|
* you should implement blitting from the glamor pixmap to the wayland
|
|
|
|
* pixmap here. Otherwise, this callback is optional.
|
|
|
|
*/
|
|
|
|
void (*post_damage)(struct xwl_window *xwl_window,
|
|
|
|
PixmapPtr pixmap, RegionPtr region);
|
|
|
|
|
|
|
|
/* Called by Xwayland to confirm with the egl backend that the given
|
|
|
|
* pixmap is completely setup and ready for display on-screen. This
|
|
|
|
* callback is optional.
|
|
|
|
*/
|
|
|
|
Bool (*allow_commits)(struct xwl_window *xwl_window);
|
|
|
|
};
|
2018-04-20 20:38:03 +02:00
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
struct xwl_screen {
|
|
|
|
int width;
|
|
|
|
int height;
|
|
|
|
int depth;
|
|
|
|
ScreenPtr screen;
|
|
|
|
int expecting_event;
|
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
|
|
|
enum RootClipMode root_clip_mode;
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
int wm_fd;
|
|
|
|
int listen_fds[5];
|
|
|
|
int listen_fd_count;
|
|
|
|
int rootless;
|
2014-06-16 20:34:55 +02:00
|
|
|
int glamor;
|
2018-03-13 16:00:53 +01:00
|
|
|
int present;
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
CreateScreenResourcesProcPtr CreateScreenResources;
|
|
|
|
CloseScreenProcPtr CloseScreen;
|
|
|
|
RealizeWindowProcPtr RealizeWindow;
|
|
|
|
UnrealizeWindowProcPtr UnrealizeWindow;
|
2018-05-04 03:07:31 +02:00
|
|
|
DestroyWindowProcPtr DestroyWindow;
|
2016-06-21 13:54:35 +02:00
|
|
|
XYToWindowProcPtr XYToWindow;
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
struct xorg_list output_list;
|
|
|
|
struct xorg_list seat_list;
|
|
|
|
struct xorg_list damage_window_list;
|
|
|
|
|
|
|
|
int wayland_fd;
|
|
|
|
struct wl_display *display;
|
|
|
|
struct wl_registry *registry;
|
|
|
|
struct wl_registry *input_registry;
|
|
|
|
struct wl_compositor *compositor;
|
2016-01-16 02:29:37 +01:00
|
|
|
struct zwp_tablet_manager_v2 *tablet_manager;
|
2014-03-12 00:11:39 +01:00
|
|
|
struct wl_shm *shm;
|
|
|
|
struct wl_shell *shell;
|
2016-09-29 04:40:01 +02:00
|
|
|
struct zwp_relative_pointer_manager_v1 *relative_pointer_manager;
|
2016-09-29 04:42:13 +02:00
|
|
|
struct zwp_pointer_constraints_v1 *pointer_constraints;
|
2017-07-12 11:51:08 +02:00
|
|
|
struct zwp_xwayland_keyboard_grab_manager_v1 *wp_grab;
|
2017-09-07 17:43:16 +02:00
|
|
|
struct zxdg_output_manager_v1 *xdg_output_manager;
|
2014-03-12 00:11:39 +01:00
|
|
|
uint32_t serial;
|
|
|
|
|
|
|
|
#define XWL_FORMAT_ARGB8888 (1 << 0)
|
|
|
|
#define XWL_FORMAT_XRGB8888 (1 << 1)
|
|
|
|
#define XWL_FORMAT_RGB565 (1 << 2)
|
|
|
|
|
|
|
|
int prepare_read;
|
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 wait_flush;
|
2014-06-16 20:34:55 +02:00
|
|
|
|
2018-02-28 02:19:44 +01:00
|
|
|
uint32_t num_formats;
|
|
|
|
struct xwl_format *formats;
|
2014-06-16 20:34:55 +02:00
|
|
|
void *egl_display, *egl_context;
|
2018-04-20 20:38:03 +02:00
|
|
|
|
2018-06-05 19:38:43 +02:00
|
|
|
struct xwl_egl_backend gbm_backend;
|
|
|
|
struct xwl_egl_backend eglstream_backend;
|
|
|
|
/* pointer to the current backend for creating pixmaps on wayland */
|
|
|
|
struct xwl_egl_backend *egl_backend;
|
2018-04-20 20:38:03 +02:00
|
|
|
|
2014-06-16 20:34:55 +02:00
|
|
|
struct glamor_context *glamor_ctx;
|
2016-11-23 12:30:53 +01:00
|
|
|
|
|
|
|
Atom allow_commits_prop;
|
2014-03-12 00:11:39 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct xwl_window {
|
|
|
|
struct xwl_screen *xwl_screen;
|
|
|
|
struct wl_surface *surface;
|
|
|
|
struct wl_shell_surface *shell_surface;
|
|
|
|
WindowPtr window;
|
|
|
|
DamagePtr damage;
|
|
|
|
struct xorg_list link_damage;
|
2014-06-30 19:53:50 +02:00
|
|
|
struct wl_callback *frame_callback;
|
2016-11-23 12:30:53 +01:00
|
|
|
Bool allow_commits;
|
2018-03-13 16:00:53 +01:00
|
|
|
WindowPtr present_window;
|
2018-05-04 03:07:31 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
#ifdef GLAMOR_HAS_GBM
|
|
|
|
struct xwl_present_window {
|
|
|
|
struct xwl_screen *xwl_screen;
|
|
|
|
WindowPtr window;
|
|
|
|
struct xorg_list link;
|
2018-03-13 16:00:53 +01:00
|
|
|
|
2018-05-04 03:07:31 +02:00
|
|
|
uint64_t msc;
|
|
|
|
uint64_t ust;
|
2018-03-13 16:00:54 +01:00
|
|
|
|
2018-05-04 03:07:31 +02:00
|
|
|
OsTimerPtr frame_timer;
|
|
|
|
Bool frame_timer_firing;
|
2018-03-13 16:00:55 +01:00
|
|
|
|
2018-05-04 03:07:31 +02:00
|
|
|
struct wl_callback *frame_callback;
|
|
|
|
struct wl_callback *sync_callback;
|
|
|
|
|
|
|
|
struct xorg_list event_list;
|
|
|
|
struct xorg_list release_queue;
|
2018-03-13 16:00:53 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct xwl_present_event {
|
|
|
|
uint64_t event_id;
|
|
|
|
uint64_t target_msc;
|
|
|
|
|
|
|
|
Bool abort;
|
|
|
|
Bool pending;
|
|
|
|
Bool buffer_released;
|
|
|
|
|
2018-05-04 03:07:31 +02:00
|
|
|
struct xwl_present_window *xwl_present_window;
|
2018-03-13 16:00:53 +01:00
|
|
|
struct wl_buffer *buffer;
|
|
|
|
|
|
|
|
struct xorg_list list;
|
2014-03-12 00:11:39 +01:00
|
|
|
};
|
2018-04-16 09:39:09 +02:00
|
|
|
#endif
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
#define MODIFIER_META 0x01
|
|
|
|
|
2015-05-27 18:41:58 +02:00
|
|
|
struct xwl_touch {
|
|
|
|
struct xwl_window *window;
|
|
|
|
int32_t id;
|
|
|
|
int x, y;
|
|
|
|
struct xorg_list link_touch;
|
|
|
|
};
|
|
|
|
|
2016-09-13 09:17:08 +02:00
|
|
|
struct xwl_pointer_warp_emulator {
|
|
|
|
struct xwl_seat *xwl_seat;
|
|
|
|
struct xwl_window *locked_window;
|
|
|
|
struct zwp_locked_pointer_v1 *locked_pointer;
|
|
|
|
};
|
|
|
|
|
2016-11-04 19:36:10 +01:00
|
|
|
struct xwl_cursor {
|
|
|
|
void (* update_proc) (struct xwl_cursor *);
|
|
|
|
struct wl_surface *surface;
|
|
|
|
struct wl_callback *frame_cb;
|
|
|
|
Bool needs_update;
|
|
|
|
};
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
struct xwl_seat {
|
|
|
|
DeviceIntPtr pointer;
|
2016-09-13 16:23:49 +02:00
|
|
|
DeviceIntPtr relative_pointer;
|
2014-03-12 00:11:39 +01:00
|
|
|
DeviceIntPtr keyboard;
|
2015-05-27 18:41:59 +02:00
|
|
|
DeviceIntPtr touch;
|
2016-01-16 02:01:38 +01:00
|
|
|
DeviceIntPtr stylus;
|
|
|
|
DeviceIntPtr eraser;
|
|
|
|
DeviceIntPtr puck;
|
2014-03-12 00:11:39 +01:00
|
|
|
struct xwl_screen *xwl_screen;
|
|
|
|
struct wl_seat *seat;
|
|
|
|
struct wl_pointer *wl_pointer;
|
2016-09-13 09:17:04 +02:00
|
|
|
struct zwp_relative_pointer_v1 *wp_relative_pointer;
|
2014-03-12 00:11:39 +01:00
|
|
|
struct wl_keyboard *wl_keyboard;
|
2015-05-27 18:41:59 +02:00
|
|
|
struct wl_touch *wl_touch;
|
2016-01-16 02:29:37 +01:00
|
|
|
struct zwp_tablet_seat_v2 *tablet_seat;
|
2014-03-12 00:11:39 +01:00
|
|
|
struct wl_array keys;
|
|
|
|
struct xwl_window *focus_window;
|
2017-12-04 16:55:13 +01:00
|
|
|
struct xwl_window *tablet_focus_window;
|
2014-03-12 00:11:39 +01:00
|
|
|
uint32_t id;
|
|
|
|
uint32_t pointer_enter_serial;
|
|
|
|
struct xorg_list link;
|
|
|
|
CursorPtr x_cursor;
|
2016-11-04 19:36:10 +01:00
|
|
|
struct xwl_cursor cursor;
|
2016-06-23 15:31:30 +02:00
|
|
|
WindowPtr last_xwindow;
|
2014-03-12 00:11:39 +01:00
|
|
|
|
2015-05-27 18:41:58 +02:00
|
|
|
struct xorg_list touches;
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
size_t keymap_size;
|
|
|
|
char *keymap;
|
|
|
|
struct wl_surface *keyboard_focus;
|
2016-03-09 10:31:58 +01:00
|
|
|
|
2018-08-06 08:09:26 +02:00
|
|
|
struct xorg_list axis_discrete_pending;
|
2016-03-09 10:31:58 +01:00
|
|
|
struct xorg_list sync_pending;
|
2016-09-13 09:17:03 +02:00
|
|
|
|
2016-09-13 09:17:08 +02:00
|
|
|
struct xwl_pointer_warp_emulator *pointer_warp_emulator;
|
|
|
|
|
2016-09-13 09:17:07 +02:00
|
|
|
struct xwl_window *cursor_confinement_window;
|
|
|
|
struct zwp_confined_pointer_v1 *confined_pointer;
|
|
|
|
|
2016-09-13 09:17:03 +02:00
|
|
|
struct {
|
|
|
|
Bool has_absolute;
|
|
|
|
wl_fixed_t x;
|
|
|
|
wl_fixed_t y;
|
2016-09-13 09:17:04 +02:00
|
|
|
|
|
|
|
Bool has_relative;
|
|
|
|
double dx;
|
|
|
|
double dy;
|
|
|
|
double dx_unaccel;
|
|
|
|
double dy_unaccel;
|
2016-09-13 09:17:03 +02:00
|
|
|
} pending_pointer_event;
|
2016-10-14 23:50:18 +02:00
|
|
|
|
|
|
|
struct xorg_list tablets;
|
|
|
|
struct xorg_list tablet_tools;
|
|
|
|
struct xorg_list tablet_pads;
|
2017-07-12 11:51:08 +02:00
|
|
|
struct zwp_xwayland_keyboard_grab_v1 *keyboard_grab;
|
2016-10-14 23:50:18 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
struct xwl_tablet {
|
|
|
|
struct xorg_list link;
|
|
|
|
struct zwp_tablet_v2 *tablet;
|
|
|
|
struct xwl_seat *seat;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct xwl_tablet_tool {
|
|
|
|
struct xorg_list link;
|
|
|
|
struct zwp_tablet_tool_v2 *tool;
|
|
|
|
struct xwl_seat *seat;
|
2016-10-14 23:31:46 +02:00
|
|
|
|
|
|
|
DeviceIntPtr xdevice;
|
2016-11-04 19:58:04 +01:00
|
|
|
uint32_t proximity_in_serial;
|
2018-09-20 16:32:29 +02:00
|
|
|
double x;
|
|
|
|
double y;
|
2016-10-14 23:31:46 +02:00
|
|
|
uint32_t pressure;
|
2018-09-20 16:32:29 +02:00
|
|
|
double tilt_x;
|
|
|
|
double tilt_y;
|
|
|
|
double rotation;
|
|
|
|
double slider;
|
2017-02-07 03:23:46 +01:00
|
|
|
|
|
|
|
uint32_t buttons_now,
|
|
|
|
buttons_prev;
|
2016-11-04 19:58:04 +01:00
|
|
|
|
2017-06-10 01:02:07 +02:00
|
|
|
int32_t wheel_clicks;
|
|
|
|
|
2016-11-04 19:58:04 +01:00
|
|
|
struct xwl_cursor cursor;
|
2016-10-14 23:50:18 +02:00
|
|
|
};
|
|
|
|
|
2017-02-07 06:04:46 +01:00
|
|
|
struct xwl_tablet_pad_ring {
|
|
|
|
unsigned int index;
|
|
|
|
struct xorg_list link;
|
|
|
|
struct xwl_tablet_pad_group *group;
|
|
|
|
struct zwp_tablet_pad_ring_v2 *ring;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct xwl_tablet_pad_strip {
|
|
|
|
unsigned int index;
|
|
|
|
struct xorg_list link;
|
|
|
|
struct xwl_tablet_pad_group *group;
|
|
|
|
struct zwp_tablet_pad_strip_v2 *strip;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct xwl_tablet_pad_group {
|
|
|
|
struct xorg_list link;
|
|
|
|
struct xwl_tablet_pad *pad;
|
|
|
|
struct zwp_tablet_pad_group_v2 *group;
|
|
|
|
|
|
|
|
struct xorg_list pad_group_ring_list;
|
|
|
|
struct xorg_list pad_group_strip_list;
|
|
|
|
};
|
|
|
|
|
2016-10-14 23:50:18 +02:00
|
|
|
struct xwl_tablet_pad {
|
|
|
|
struct xorg_list link;
|
|
|
|
struct zwp_tablet_pad_v2 *pad;
|
|
|
|
struct xwl_seat *seat;
|
2017-02-07 06:04:46 +01:00
|
|
|
|
|
|
|
DeviceIntPtr xdevice;
|
|
|
|
|
|
|
|
unsigned int nbuttons;
|
|
|
|
struct xorg_list pad_group_list;
|
2014-03-12 00:11:39 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct xwl_output {
|
|
|
|
struct xorg_list link;
|
|
|
|
struct wl_output *output;
|
2017-09-07 17:43:16 +02:00
|
|
|
struct zxdg_output_v1 *xdg_output;
|
2015-05-16 07:38:28 +02:00
|
|
|
uint32_t server_output_id;
|
2014-03-12 00:11:39 +01:00
|
|
|
struct xwl_screen *xwl_screen;
|
|
|
|
RROutputPtr randr_output;
|
|
|
|
RRCrtcPtr randr_crtc;
|
2016-07-13 19:19:09 +02:00
|
|
|
int32_t x, y, width, height, refresh;
|
2014-03-12 00:11:39 +01:00
|
|
|
Rotation rotation;
|
2017-09-07 17:43:16 +02:00
|
|
|
Bool wl_output_done;
|
|
|
|
Bool xdg_output_done;
|
2014-03-12 00:11:39 +01:00
|
|
|
};
|
|
|
|
|
2016-03-09 10:33:50 +01:00
|
|
|
void xwl_sync_events (struct xwl_screen *xwl_screen);
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
Bool xwl_screen_init_cursor(struct xwl_screen *xwl_screen);
|
|
|
|
|
|
|
|
struct xwl_screen *xwl_screen_get(ScreenPtr screen);
|
|
|
|
|
2016-11-04 19:58:04 +01:00
|
|
|
void xwl_tablet_tool_set_cursor(struct xwl_tablet_tool *tool);
|
2014-03-12 00:11:39 +01:00
|
|
|
void xwl_seat_set_cursor(struct xwl_seat *xwl_seat);
|
|
|
|
|
|
|
|
void xwl_seat_destroy(struct xwl_seat *xwl_seat);
|
|
|
|
|
2015-05-27 18:42:00 +02:00
|
|
|
void xwl_seat_clear_touch(struct xwl_seat *xwl_seat, WindowPtr window);
|
|
|
|
|
2016-09-13 09:17:08 +02:00
|
|
|
void xwl_seat_emulate_pointer_warp(struct xwl_seat *xwl_seat,
|
|
|
|
struct xwl_window *xwl_window,
|
|
|
|
SpritePtr sprite,
|
|
|
|
int x, int y);
|
|
|
|
|
|
|
|
void xwl_seat_destroy_pointer_warp_emulator(struct xwl_seat *xwl_seat);
|
|
|
|
|
|
|
|
void xwl_seat_cursor_visibility_changed(struct xwl_seat *xwl_seat);
|
|
|
|
|
2016-09-13 09:17:07 +02:00
|
|
|
void xwl_seat_confine_pointer(struct xwl_seat *xwl_seat,
|
|
|
|
struct xwl_window *xwl_window);
|
|
|
|
void xwl_seat_unconfine_pointer(struct xwl_seat *xwl_seat);
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
Bool xwl_screen_init_output(struct xwl_screen *xwl_screen);
|
|
|
|
|
|
|
|
struct xwl_output *xwl_output_create(struct xwl_screen *xwl_screen,
|
|
|
|
uint32_t id);
|
|
|
|
|
|
|
|
void xwl_output_destroy(struct xwl_output *xwl_output);
|
|
|
|
|
2016-08-08 17:57:57 +02:00
|
|
|
void xwl_output_remove(struct xwl_output *xwl_output);
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
RRModePtr xwayland_cvt(int HDisplay, int VDisplay,
|
|
|
|
float VRefresh, Bool Reduced, Bool Interlaced);
|
|
|
|
|
|
|
|
void xwl_pixmap_set_private(PixmapPtr pixmap, struct xwl_pixmap *xwl_pixmap);
|
|
|
|
struct xwl_pixmap *xwl_pixmap_get(PixmapPtr pixmap);
|
|
|
|
|
2018-04-18 16:02:02 +02:00
|
|
|
struct xwl_window *xwl_window_from_window(WindowPtr window);
|
2014-03-12 00:11:39 +01:00
|
|
|
|
|
|
|
Bool xwl_shm_create_screen_resources(ScreenPtr screen);
|
|
|
|
PixmapPtr xwl_shm_create_pixmap(ScreenPtr screen, int width, int height,
|
|
|
|
int depth, unsigned int hint);
|
|
|
|
Bool xwl_shm_destroy_pixmap(PixmapPtr pixmap);
|
|
|
|
struct wl_buffer *xwl_shm_pixmap_get_wl_buffer(PixmapPtr pixmap);
|
|
|
|
|
2018-06-05 19:38:36 +02:00
|
|
|
#ifdef XWL_HAS_GLAMOR
|
2018-06-05 19:38:42 +02:00
|
|
|
void xwl_glamor_init_backends(struct xwl_screen *xwl_screen,
|
|
|
|
Bool use_eglstream);
|
2018-06-05 19:38:43 +02:00
|
|
|
void xwl_glamor_select_backend(struct xwl_screen *xwl_screen,
|
|
|
|
Bool use_eglstream);
|
2014-06-16 20:34:55 +02:00
|
|
|
Bool xwl_glamor_init(struct xwl_screen *xwl_screen);
|
|
|
|
|
2018-02-28 02:19:43 +01:00
|
|
|
Bool xwl_screen_set_drm_interface(struct xwl_screen *xwl_screen,
|
|
|
|
uint32_t id, uint32_t version);
|
|
|
|
Bool xwl_screen_set_dmabuf_interface(struct xwl_screen *xwl_screen,
|
|
|
|
uint32_t id, uint32_t version);
|
2018-03-13 16:00:52 +01:00
|
|
|
struct wl_buffer *xwl_glamor_pixmap_get_wl_buffer(PixmapPtr pixmap,
|
|
|
|
Bool *created);
|
2018-04-20 20:38:03 +02:00
|
|
|
void xwl_glamor_init_wl_registry(struct xwl_screen *xwl_screen,
|
|
|
|
struct wl_registry *registry,
|
|
|
|
uint32_t id, const char *interface,
|
|
|
|
uint32_t version);
|
2018-06-05 19:38:41 +02:00
|
|
|
Bool xwl_glamor_has_wl_interfaces(struct xwl_screen *xwl_screen,
|
|
|
|
struct xwl_egl_backend *xwl_egl_backend);
|
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
|
|
|
void xwl_glamor_post_damage(struct xwl_window *xwl_window,
|
|
|
|
PixmapPtr pixmap, RegionPtr region);
|
|
|
|
Bool xwl_glamor_allow_commits(struct xwl_window *xwl_window);
|
2018-06-05 19:38:36 +02:00
|
|
|
void xwl_glamor_egl_make_current(struct xwl_screen *xwl_screen);
|
2014-06-16 20:34:55 +02:00
|
|
|
|
2018-04-16 09:39:09 +02:00
|
|
|
#ifdef GLAMOR_HAS_GBM
|
2018-03-13 16:00:53 +01:00
|
|
|
Bool xwl_present_init(ScreenPtr screen);
|
2018-05-04 03:07:31 +02:00
|
|
|
void xwl_present_cleanup(WindowPtr window);
|
2018-06-05 19:38:36 +02:00
|
|
|
#endif /* GLAMOR_HAS_GBM */
|
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
|
|
|
|
2016-03-09 16:21:18 +01:00
|
|
|
#ifdef XV
|
|
|
|
/* glamor Xv Adaptor */
|
|
|
|
Bool xwl_glamor_xv_init(ScreenPtr pScreen);
|
2018-06-05 19:38:36 +02:00
|
|
|
#endif /* XV */
|
|
|
|
|
|
|
|
#endif /* XWL_HAS_GLAMOR */
|
|
|
|
|
|
|
|
void xwl_screen_release_tablet_manager(struct xwl_screen *xwl_screen);
|
|
|
|
|
|
|
|
void xwl_screen_init_xdg_output(struct xwl_screen *xwl_screen);
|
2016-03-09 16:21:18 +01:00
|
|
|
|
2016-02-10 09:35:39 +01:00
|
|
|
#ifdef XF86VIDMODE
|
|
|
|
void xwlVidModeExtensionInit(void);
|
|
|
|
#endif
|
|
|
|
|
2018-04-20 20:38:03 +02:00
|
|
|
#ifdef GLAMOR_HAS_GBM
|
2018-06-05 19:38:43 +02:00
|
|
|
void xwl_glamor_init_gbm(struct xwl_screen *xwl_screen);
|
xwayland: Add glamor egl_backend for EGLStreams
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
2018-04-20 20:38:05 +02:00
|
|
|
#else
|
2018-06-05 19:38:43 +02:00
|
|
|
static inline void xwl_glamor_init_gbm(struct xwl_screen *xwl_screen)
|
xwayland: Add glamor egl_backend for EGLStreams
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
2018-04-20 20:38:05 +02:00
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef XWL_HAS_EGLSTREAM
|
2018-06-05 19:38:43 +02:00
|
|
|
void xwl_glamor_init_eglstream(struct xwl_screen *xwl_screen);
|
xwayland: Add glamor egl_backend for EGLStreams
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
2018-04-20 20:38:05 +02:00
|
|
|
#else
|
2018-06-05 19:38:43 +02:00
|
|
|
static inline void xwl_glamor_init_eglstream(struct xwl_screen *xwl_screen)
|
xwayland: Add glamor egl_backend for EGLStreams
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
2018-04-20 20:38:05 +02:00
|
|
|
{
|
|
|
|
}
|
2018-04-20 20:38:03 +02:00
|
|
|
#endif
|
|
|
|
|
2014-03-12 00:11:39 +01:00
|
|
|
#endif
|