1<?xml version='1.0' encoding='utf-8' ?> 2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ 3<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent"> 4%BOOK_ENTITIES; 5]> 6<chapter id="chap-X11-Application-Support"> 7 <title>X11 Application Support</title> 8 <section id="sect-X11-Application-Support-introduction"> 9 <title>Introduction</title> 10 <para> 11 Being able to run existing X11 applications is crucial for the adoption 12 of Wayland, especially on desktops, as there will always be X11 13 applications that have not been or cannot be converted into Wayland 14 applications, and throwing them all away would be prohibitive. 15 Therefore a Wayland compositor often needs to support running X11 16 applications. 17 </para> 18 <para> 19 X11 and Wayland are different enough that there is no "simple" way to 20 translate between them. Most of X11 is uninteresting to a Wayland 21 compositor. That, combined with the gigantic implementation effort needed 22 to support X11, makes it intractable to just write X11 support directly in 23 a Wayland compositor. The implementation would be nothing short of a 24 real X11 server. 25 </para> 26 <para> 27 Therefore, Wayland compositors should use Xwayland, the X11 server that 28 lives in the Xorg server source code repository and shares most of the 29 implementation with the Xorg server. Xwayland is a complete X11 server, 30 just like Xorg is, but instead of driving the displays and opening input 31 devices, it acts as a Wayland client. The rest of this chapter talks 32 about how Xwayland works. 33 </para> 34 <para> 35 For integration and architecture reasons, while Xwayland is a Wayland 36 client of the Wayland compositor, the Wayland compositor is an X11 client 37 of Xwayland. This circular dependency requires special care from the 38 Wayland compositor. 39 </para> 40 </section> 41 <section id="sect-X11-Application-Support-two-modes"> 42 <title>Two Modes for Foreign Windows</title> 43 <para> 44 In general, windows from a foreign window system can be presented in one 45 of two ways: rootless and rootful (not rootless). 46 </para> 47 <para> 48 In rootful mode, the foreign window system as a whole is represented as a 49 window (or more) of its own. You have a native window, inside which all 50 the foreign windows are. The advantage of this approach in Xwayland's 51 case is that you can run your favourite X11 window manager to manage your 52 X11 applications. The disadvantage is that the foreign windows do not 53 integrate with the native desktop. Therefore this mode is not usually 54 used. 55 </para> 56 <para> 57 In rootless mode, each foreign window is a first-class resident among the 58 native windows. Foreign windows are not confined inside a native window 59 but act as if they were native windows. The advantage is that one can 60 freely stack and mix native and foreign windows, which is not possible in 61 rootful mode. The disadvantage is that this mode is harder to implement 62 and fundamental differences in window systems may prevent some things 63 from working. With rootless Xwayland, the Wayland compositor must take 64 the role as the X11 window manager, and one cannot use any other X11 65 window manager in its place. 66 </para> 67 <para> 68 This chapter concentrates on the rootless mode, and ignores the rootful 69 mode. 70 </para> 71 </section> 72 <section id="sect-X11-Application-Support-architecture"> 73 <title>Architecture</title> 74 <para> 75 A Wayland compositor usually takes care of launching Xwayland. 76 Xwayland works in cooperation with a Wayland compositor as follows: 77 </para> 78 <figure> 79 <title>Xwayland architecture diagram</title> 80 <mediaobjectco> 81 <imageobjectco> 82 <imageobject> 83 <imagedata fileref="images/xwayland-architecture.png" format="PNG" /> 84 </imageobject> 85 </imageobjectco> 86 </mediaobjectco> 87 </figure> 88 <para> 89 An X11 application connects to Xwayland just like it would connect to any 90 X server. Xwayland processes all the X11 requests. On the other end, 91 Xwayland is a Wayland client that connects to the Wayland compositor. 92 </para> 93 <para> 94 The X11 window manager (XWM) is an integral part of the Wayland 95 compositor. XWM uses the usual X11 window management protocol to manage 96 all X11 windows in Xwayland. Most importantly, XWM acts as a bridge 97 between Xwayland window state and the Wayland compositor's window manager 98 (WWM). This way WWM can manage all windows, both native Wayland and X11 99 (Xwayland) windows. This is very important for a coherent user 100 experience. 101 </para> 102 <para> 103 Since Xwayland uses Wayland for input and output, it does not have any 104 use for the device drivers that Xorg uses. None of the xf86-video-* or 105 xf86-input-* modules are used. There also is no configuration file for 106 the Xwayland server. For optional hardware accelerated rendering, 107 Xwayland uses GLAMOR. 108 </para> 109 <para> 110 A Wayland compositor usually spawns only one Xwayland instance. This is 111 because many X11 applications assume they can communicate with other X11 112 applications through the X server, and this requires a shared X server 113 instance. This also means that Xwayland does not protect nor isolate X11 114 clients from each other, unless the Wayland compositor specifically 115 chooses to break the X11 client intercommunications by spawning 116 application specific Xwayland instances. X11 clients are naturally 117 isolated from Wayland clients. 118 </para> 119 <para> 120 Xwayland compatibility compared to a native X server will probably never 121 reach 100%. Desktop environment (DE) components, specifically X11 window 122 managers, are practically never supported. An X11 window manager would 123 not know about native Wayland windows, so it could manage only X11 124 windows. On the other hand, there must be an XWM that reserves the 125 exclusive window manager role so that the Wayland compositor could show 126 the X11 windows appropriately. For other DE components, like pagers and 127 panels, adding the necessary interfaces to support them in WWM through XWM 128 is often considered not worthwhile. 129 </para> 130 </section> 131 <section id="sect-X11-Application-Support-xwm"> 132 <title>X Window Manager (XWM)</title> 133 <para> 134 From the X11 point of view, the X window manager (XWM) living inside a 135 Wayland compositor is just like any other window manager. The difference 136 is mostly in which process it resides in, and the few extra conventions 137 in the X11 protocol to support Wayland window management (WWM) 138 specifically. 139 </para> 140 <para> 141 There are two separate asynchronous communication channels between 142 Xwayland and a Wayland compositor: one uses the Wayland protocol, and the 143 other one, solely for XWM, uses X11 protocol. This setting demands great 144 care from the XWM implementation to avoid (random) deadlocks with 145 Xwayland. It is often nearly impossible to prove that synchronous or 146 blocking X11 calls from XWM cannot cause a deadlock, and therefore it is 147 strongly recommended to make all X11 communications asynchronous. All 148 Wayland communications are already asynchronous by design. 149 </para> 150 <section id="sect-X11-Application-Support-xwm-window-identification"> 151 <title>Window identification</title> 152 <para> 153 In Xwayland, an X11 window may have a corresponding wl_surface object 154 in Wayland. The wl_surface object is used for input and output: it is 155 referenced by input events and used to provide the X11 window content 156 to the Wayland compositor. The X11 window and the wl_surface live in 157 different protocol streams, and they need to be matched for XWM to do 158 its job. 159 </para> 160 <para> 161 When Xwayland creates a wl_surface on Wayland, it will also send an X11 162 ClientMessage of type atom "WL_SURFACE_ID" to the X11 window carrying 163 the wl_surface Wayland object ID as the first 32-bit data element. This 164 is how XWM can associate a wl_surface with an X11 window. Note that 165 the request to create a wl_surface and the ID message may arrive in any 166 order in the Wayland compositor. 167 </para> 168 </section> 169 </section> 170</chapter> 171
