[PATCH wayland v2] doc: start documenting Xwayland
Jonas Ådahl
jadahl at gmail.com
Tue Dec 20 04:12:54 UTC 2016
On Mon, Dec 05, 2016 at 03:52:19PM +0200, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>
> This is a rough intro to what Xwayland is and does, with just one
> implementation detail so far (Window identification).
>
> I paid no attention to formatting details, those can be polished in
> follow-ups. I just want the prose out.
>
> I also just quickly whacked up the diagram, would be happy to see
> someone replace it with a nicer one. I just didn't have time to learn
> dot for now.
>
> v2:
> - typo fix
> - rephrase "talking to hardware" as "driving the displays"
> - mention circular dependency in intro
> - add section to explain rootless and rootful modes
> - remove paragraph about Xwayland protocol usage
> - move TBD part to the end under a new section header
>
> Cc: Olivier Fourdan <ofourdan at redhat.com>
> Cc: Jonas Ådahl <jadahl at gmail.com>
> Cc: Daniel Stone <daniel at fooishbar.org>
> Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> ---
> doc/publican/Makefile.am | 5 +-
> doc/publican/sources/Wayland.xml | 1 +
> doc/publican/sources/Xwayland.xml | 207 +++++++++++++++++++++
> .../sources/images/xwayland-architecture.png | Bin 0 -> 7611 bytes
> 4 files changed, 212 insertions(+), 1 deletion(-)
> create mode 100644 doc/publican/sources/Xwayland.xml
> create mode 100644 doc/publican/sources/images/xwayland-architecture.png
>
> diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am
> index 57728a0..e861fe6 100644
> --- a/doc/publican/Makefile.am
> +++ b/doc/publican/Makefile.am
> @@ -24,9 +24,11 @@ publican_sources = \
> $(srcdir)/sources/Preface.xml \
> $(srcdir)/sources/Revision_History.xml \
> $(srcdir)/sources/Protocol.xml \
> + $(srcdir)/sources/Xwayland.xml \
> $(srcdir)/sources/Compositors.xml \
> $(srcdir)/sources/images/icon.svg \
> $(srcdir)/sources/images/wayland.png \
> + $(srcdir)/sources/images/xwayland-architecture.png \
> $(srcdir)/sources/Client.xml \
> $(srcdir)/sources/Server.xml
>
> @@ -43,7 +45,8 @@ css_sources = \
>
> img_sources = \
> $(srcdir)/sources/images/icon.svg \
> - $(srcdir)/sources/images/wayland.png
> + $(srcdir)/sources/images/wayland.png \
> + $(srcdir)/sources/images/xwayland-architecture.png
>
> doxygen_img_sources := \
> $(doxydir)/xml/wayland-architecture.png \
> diff --git a/doc/publican/sources/Wayland.xml b/doc/publican/sources/Wayland.xml
> index 2f47f13..0457c15 100644
> --- a/doc/publican/sources/Wayland.xml
> +++ b/doc/publican/sources/Wayland.xml
> @@ -11,6 +11,7 @@
> <xi:include href="Compositors.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
> <xi:include href="Architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
> <xi:include href="Protocol.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
> + <xi:include href="Xwayland.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
> <xi:include href="ProtocolSpec.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
> <xi:include href="Client.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
> <xi:include href="Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
> diff --git a/doc/publican/sources/Xwayland.xml b/doc/publican/sources/Xwayland.xml
> new file mode 100644
> index 0000000..20e94e3
> --- /dev/null
> +++ b/doc/publican/sources/Xwayland.xml
> @@ -0,0 +1,207 @@
> +<?xml version='1.0' encoding='utf-8' ?>
> +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
> +<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent">
> +%BOOK_ENTITIES;
> +]>
> +<chapter id="chap-X11-Application-Support">
> + <title>X11 Application Support</title>
> + <section id="sect-X11-Application-Support-introduction">
> + <title>Introduction</title>
> + <para>
> + Being able to run existing X11 applications is crucial for the adoption
> + of Wayland, especially on desktops, as there will always be X11
> + applications that have not been or cannot be converted into Wayland
> + applications, and throwing them all away would be prohibitive.
> + Therefore a Wayland compositor often needs to support running X11
> + applications.
> + </para>
> + <para>
> + X11 and Wayland are different enough that there is no "simple" way to
> + translate between them. Most of X11 is uninteresting to a Wayland
> + compositor. That combined with the gigantic implementation effort needed
> + to support X11 makes it intractable to just write X11 support directly in
> + a Wayland compositor. The implementation would be nothing short from a
> + real X11 server.
> + </para>
> + <para>
> + Therefore Wayland compositors should use Xwayland, the X11 server that
> + lives in the Xorg server source code repository and shares most of the
> + implementation with the Xorg server. Xwayland is a complete X11 server,
> + just like Xorg is, but instead of driving the displays and opening input
> + devices, it acts as a Wayland client. The rest of this chapter talks
> + about how Xwayland works.
> + </para>
> + <para>
> + For integration and architecture reasons, while Xwayland is a Wayland
> + client of the Wayland compositor, the Wayland compositor is an X11 client
> + of Xwayland. This circular dependency requires special care from the
> + Wayland compositor.
> + </para>
> + </section>
> + <section id="sect-X11-Application-Support-two-modes">
> + <title>Two Modes for Foreign Windows</title>
> + <para>
> + In general, windows from a foreign window system can be presented in one
> + of two ways: rootless and rootful (not rootless).
> + </para>
> + <para>
> + In rootful mode, the foreign window system as a whole is represented as
> + a window (or more) of its own. You have a native window, inside which
> + all the foreign windows are. The pro of this approach is that you can
s/pro/advantage/
> + even run traditional X11 window managers in Xwayland's case to manage
> + your X11 applications. The con is that the foreign windows do not
s/con/disadvantage/
> + integrate with the native desktop. Therefore this mode is not usually
> + used.
> + </para>
> + <para>
> + In rootless mode, each foreign window is a first-class resident among the
> + native windows. Foreign windows are not confined inside a native window
> + but act as if they were native windows. The pro is that one can freely
> + stack and mix native and foreign windows, which is not possible in
> + rootful mode. The con is that this mode is harder to implement and
> + fundamental differences in window systems may prevent some things from
> + working. With rootless Xwayland, one cannot run a normal X11 window
> + manager.
Same as above in this paragraph.
And the last part is not completely correct. In mutter we use the
"normal" window manager, just a bit differently, but for the most part
it's the good old metacity that manages the X11 windows as it has been
doing for ages. The difference is that the window manager used
differently here nad there and it needs to be combined with the
compositor.
Maybe we can change this to something like: "With rootless Xwayland, the
Wayland compositor must take the role as the X11 window manager, and one
cannot use any other X11 window manager in its place." ?
> + </para>
> + <para>
> + This chapter concentrates on the rootless mode, and ignores the rootful
> + mode.
> + </para>
> + </section>
> + <section id="sect-X11-Application-Support-architecture">
> + <title>Architecture</title>
> + <para>
> + A Wayland compositor usually takes care of launching Xwayland.
> + Xwayland works in cooperation with a Wayland compositor as follows:
> + </para>
> + <figure>
> + <title>Xwayland architecture diagram</title>
> + <mediaobjectco>
> + <imageobjectco>
> + <imageobject>
> + <imagedata fileref="images/xwayland-architecture.png" format="PNG" />
> + </imageobject>
> + </imageobjectco>
> + </mediaobjectco>
> + </figure>
> + <para>
> + An X11 application connects to Xwayland just like it would connect to any
> + X server. Xwayland processes all the X11 requests. On the other end,
> + Xwayland is a Wayland client that connects to the Wayland compositor.
> + </para>
> + <para>
> + The X11 window manager (XWM) is an integral part of the Wayland
> + compositor. XWM uses the usual X11 window management protocol to manage
> + all X11 windows in Xwayland. Most importantly, XWM acts as a bridge
> + between Xwayland window state and the Wayland compositor's window manager
> + (WWM). This way WWM can manage all windows, both native Wayland and X11
> + (Xwayland) windows. This is very important for a coherent user
> + experience.
> + </para>
> + <para>
> + Since Xwayland uses Wayland for input and output, it does not have any
> + use for the device drivers that Xorg uses. None of the xf86-video-* or
> + xf86-input-* modules are used. There also is no configuration file for
> + the Xwayland server. For optional hardware accelerated rendering,
> + Xwayland uses GLAMOR.
> + </para>
> + <para>
> + A Wayland compositor usually spawns only one Xwayland instance. This is
> + because many X11 applications assume they can communicate with other X11
> + applications through the X server, and this requires a shared X server
> + instance. This also means, that Xwayland does not protect nor isolate X11
> + clients from each other, unless the Wayland compositor specifically
> + chooses to break the X11 client intercommunications by spawning
> + application specific Xwayland instances. X11 clients are naturally
> + isolated from Wayland clients though.
> + </para>
> + <para>
> + Xwayland compatibility compared to a native X server will probably never
> + reach 100%. Desktop environment (DE) components, specifically X11 window
> + managers, are practically never supported. An X11 window manager would
> + not know about native Wayland windows, so it could manage only X11
> + windows. OTOH, there must be an XWM that reserves the exclusive window
> + manager role so that the Wayland compositor could show the X11 windows
> + appropriately. For other DE components like pagers and panels adding the
> + necessary interfaces to support them in WWM through XWM is often
> + considered not worthwhile.
> + </para>
> + </section>
> + <section id="sect-X11-Application-Support-xwm">
> + <title>X Window Manager (XWM)</title>
> + <para>
> + From the X11 point of view, the X window manager (XWM) living inside a
> + Wayland compositor is just like any other window manager. The difference
> + is mostly in which process it resides in, and the few extra conventions
> + in the X11 protocol to support Wayland window management (WWM)
> + specifically.
> + </para>
> + <para>
> + There are two separate, asynchronous communication channels between
> + Xwayland and a Wayland compositor: one uses the Wayland protocol, and the
> + other one solely for XWM uses X11 protocol. This setting demands great
> + care from the XWM implementation to avoid (random) deadlocks with
> + Xwayland. It is often nearly impossible to prove that synchronous or
> + blocking X11 calls from XWM cannot cause a deadlock, and therefore it is
> + strongly recommended to make all X11 communications asynchronous. All
> + Wayland communications are already asynchonous by design.
> + </para>
> + <para>
> + The Wayland connection carries window content and input events, while the
> + X11 connection carries window management messages. This design avoids the
> + need to create a Wayland protocol extension specific to Xwayland. It also
> + lets Xwayland to be agnostic of any Wayland shell protocols, allowing
> + Xwayland to be better integratable in various environments. Also many
> + Wayland desktop compositors started with an existing X11 window manager,
> + and this design allows them to use their existing code.
This might not be true in the future. One thing that has been discussed
is to introduce a "fullscreen" feature similar to
wl_shell_surface_set_fullscreen/xdg_toplevel_set_fullscreen used by
Xwayland to emulate mode setting. This may or may not be shared with
xdg_shell clients, as things might work a bit differently. The
underlying issue being that some games fail to function if modesetting
fails. There are also a fairly undocumented convention for allowing
pointer locking via Xwayland, which is not to far from having a separate
protocol. There might be other reasons for eventually introducing a
wp_xwayland protocol to give the Wayland compositor more control or more
state normally not available to traditional XWM:s.
Jonas
> + </para>
> + <section id="sect-X11-Application-Support-xwm-window-identification">
> + <title>Window identification</title>
> + <para>
> + In Xwayland, an X11 window may have a corresponding wl_surface object
> + in Wayland. The wl_surface object is used for input and output: it is
> + referenced by input events and used to provide the X11 window content
> + to the Wayland compositor. The X11 window and the wl_surface live in
> + different protocol streams, and they need to be matched for XWM to do
> + its job.
> + </para>
> + <para>
> + When Xwayland creates a wl_surface on Wayland, it will also send an X11
> + ClientMessage of type atom "WL_SURFACE_ID" to the X11 window carrying
> + the wl_surface Wayland object ID as the first 32-bit data element. This
> + is how XWM can associate a wl_surface with an X11 window. Note, that
> + the request to create a wl_surface and the ID message may arrive in any
> + order in the Wayland compositor.
> + </para>
> + </section>
> + </section>
> +<!-- TBD
> + <section id="sect-X11-Application-Support-details-issues">
> + <title>Implementation Details and Known Issues</title>
> + <para>
> + This section discusses the specific Xwayland implementation as of
> + xorg-xserver release 1.19.
> + </para>
> + <section id="sect-X11-Application-Support-output">
> + <title>Output Characteristics</title>
> + <para>
> + Output restrictions?
> + Absolute window positioning?
> + Front buffer rendering?
> + Does Xwayland draw to buffers that are reserved by the Wayland compositor?
> + GLAMOR?
> + Each window drawn to separate off-screen buffer.
> + </para>
> + </section>
> + <section id="sect-X11-Application-Support-input">
> + <title>Input Characteristics</title>
> + <para>
> + Input arbitrated by the Wayland compositor, but also by Xwayland?
> + Careful cooperation...
> +
> + How X11 pointer warping, confinement etc. are supported?
> + </para>
> + </section>
> + </section>
> +-->
> +</chapter>
> diff --git a/doc/publican/sources/images/xwayland-architecture.png b/doc/publican/sources/images/xwayland-architecture.png
> new file mode 100644
> index 0000000000000000000000000000000000000000..f24dc1837f2e190c9d38719420a844aeb5997efa
> GIT binary patch
> literal 7611
> zcmb`M2UJsQx`q)I=^!9T^#n0UM?ktDD2S1wp?9SBE*;SWNbe|wdJqEAdq)riaw1JY
> zdI<=j_Yz7d_jk&fxpU8)nLBH;Ru(%DcK+=D``+()-yQZ;^$`Ur6Da`!0mWmbhj0Rd
> z3&P-OMob8PGhO9-27X+0lYgv1OiVm6t2P5(k~k~rx)Bgu`TFB|p*~_UlYoHL=<!22
> z4X?EIDc`5+R?}Cu7GqzjJmeT7B&uRfR*KUvRxFBE-A`wIwDohZj^jp0mriUtcXote
> z1D{br`g%p<-FIbtbEJ{<uRE9{8pN-;bN7CSy>;nSoP6=<(bY%PJS4RoeR$L|+aL!!
> zA=*3MPc}fDv(MW#10#VRS&Z!>$>Qx_-M^G(a<qf(^=c9l7Vel9?)x at 6x^&Znf?$Rq
> zp5zmI{^;eVr|Rkn%23)y(gPee$@mN_5a7~!zfh}qyxc5=jA+Mxcd>7Cd3iQzOl4uh
> zsf918tD~gtqe_Yh`tHTkH7nUv8UF^m&K(mOnZCZ~E}~?g*g0rlDJVe+B4U*Z=phIK
> zUU{JlIzi at yWyI)9CRcxa>L0x!PMcGhkI$j&9p8zos;a7wk7P^tY0L|&kf<4$(Y{x?
> zugXP+ugmV++uLX~I&mN+C1rS6t2rGGBQE!T$}0LZkN40VcE~Lkp3lq0rQ7JS-tc0T
> zl1=)<)7y$oT+wrWetzui>?^CQ!S7B^`~m{b>+0&>y`vA|+k!Q%Z11d?)5z1%(gp?w
> zer{`{=hG8OS$_&sfevOp2oZIf<`rq)?qrT(yLUVjNENhNF<$$LXZt;>i;;nt?anHX
> z95Xo)L!^$rexX+3knIaY!}K2RkSnO?*{XSDR8&bYWDs at OL-suprl>@CVCzo_XqFoB
> ziQaUnqrl}g9yu#ZOGz_4P8z>WN=!TxlUHj@(ok6`%)?XI)YMc|#49XZSy*UiK7sD*
> zJO3Ub(9qauXJ^-AS^3pSOKW&yLSIjhiI#TvJ^gi=QlF-#<7>aHt*za)8}3F3hfr7e
> z?5}{A*^gpq3X>=fFCPz%&=fIyx16p!2 at 46$yLxMBz1zo~<1y#WXUD5ouU at sVun@3)
> zJ-b_i>bmT<w^e^;KkU60Q at k2evzXo^NktaJ&}(@?C&XNmtXk6F=NVa9U^R;D-`U<j
> z-2c$2Rf6j3YP7jfd7-mYdU|>Z<I?hAUajMlYmW|Fw`n<X*BaFAcyHM>iQw~#y`^Vo
> zrn-V!&VQ{r7WJg43LRd5e}7Z$S@?~YhqGYYe0+S;B*P!FGm1G*COdhUn0zu9iaN3^
> z&L3Lwoc7LZXc*7WF0-7hbFn{7U!I%0`KR(m9 at -r?E*s&Gemo>z5J%5((1fM3W%hp>
> z<Ndw5c9*rWvC*%wpG|UebsZQSJhIpbD3X%0-?Ptf at f-CSx%B2i-e3m`#mUL34zshh
> z)zjBM@;DyEM6tZ at uk`NRmJ^za`D?-QLFQ*#14)DB*TP4?Gor4b-JgVog|)V}Ha9m%
> z(DTtW($jl?+HS=l9G5o(&V8+{7C(njsb$LWdGPV>yqXJ?7(8|N at UXP7(A3sehpDTp
> zmm0T}XmEG%heN<(1g#n}e=7{Djmi2#?b6=f-i3+ak?Y0A_U at xgW72bnW&4J-0*MHO
> zE*x%pYT;2vPfsuEw$QDfry6D$TKK&8clvntRQakwv!AZc#?n%m4G9%hrie{Eu|;`S
> zVd0a~5i+qWL_`_V-lqP3mfgv-k#<bwM4Kt0Ki#>ry*5@!seN>O{PO(t08}17e;BKw
> zq2cW8tnA5F;OFYWJT)g9o98Q0k2qV$iik-`NsX#jl3GrXVyJlP_Zr;bU7s0>PY>r}
> zK0 at AIa?91B7clbMn3PDRx~_zTe>B>}qB(-xU%dEuw2(>^*m{fxn at r2h?7KdGSKu*p
> zLD^+(vVIWyjs<nPqTM3TO9Fu*U3V9HMBUzWn2y!E<t4SpoAlDf^;CtC45su{Ej!Rc
> zThqAMS8Zr%b17171}C7(KTD_^L@)@Hl$PctnzmJODyOobyeEPlH?5y`Z)|L=j+90i
> zcDMn#IzL3o5<|cyHh6AMfAl?QFA3%2(JB)6I}}9jogQFXytdzuVx`3##;ay#OctZ%
> zK0Y=x%XW)_dWD3ClUm7YZ+ik+ZCbV0`s8A8|Ng5{&6800ie`Y^N19y9-b$-J101WT
> zfQse)`}aLPYezL-r6NQf#t$$7n<?eLb;*CM%zxOr|CYA@<qU6xz8jlbEpkpy(Zw%A
> z1_lOd?8n*!7U$=4^710|sUqVw)(B1Pm)si;4-e<(&0#hwDk^q%g`?M6KbZ9HQNxfG
> zIXUL*<JGIf#Zq2dzsP6JOlWdz`ugJQ-4?~8 at e8R=8<>_GG&F6c-^F`D)3LL^Z*I<@
> z9{Bc+j+ND+T!$Ev2(Q*F9$768DO>JynasH7OL*}jIE979El3U$d5fRF7lV<NmBqZp
> zZ^Xqa_r)bAUuR)qp{K90?q|<(>5OD_aB#>BIP-q_ at +|ZGWO1U_3Dw!TQ+OK*O<4Y#
> z^&nNu2^!R$E+xjzU67mmhI(hc7Ne-3 at Ns`we|VyHS&jJFZMyaK^$<$d?`k>1!oonB
> z4ww3~%gO{t)+#u&r*q27<1njXw4C9FU89A?#hPH8R5z5As9K*aWyiR>xq+8s_F%}=
> z*Vm_tI=oL at ac|h#a?aO)5yvTU_*s24D($zvjbs+J7Y{g-MrwGy89m?(O75|I$%j#a
> zCNM at R!tz^9wtmgi($JtgKgs{_!5OE+=5_dHrWNgXa_FL?qob}qh<uU+Rm+$h8$;LL
> zkbODX*S9&SCW}nmn5gXo$AzWM?-PkGUHUdOw7<9aZFpEO&w8#iYG`PPjDdgNiL`JH
> zuaAi^9<~<g=;%<)F8}a>7|n8vO4{$i){J>>PR`nBd7yD`SJx926>Jjd2A;RD8!~=M
> zTn<i7U{Zn|PaK$P^i)d|e};sEz3!4!U}a^Mlas?@u_r3e-}(pO&5b_#+!Yno;!j${
> zVj+m^`PU&%#B6EZ<))&kgM))WaN7BU6iSq#(|2Ekx=854g2e$5H68iB9;@sX4d?bC
> z*}B<eNB9>Y$z2pgDCg(rn`&=ofBUA9fadVH=17j-W6{*qWQuxIw!Mr)2wQ1sYSzCr
> zh<R=96CEBNewmD(THamKP*Za#n2dpmnHh+?yJY%mgl?IMoPt8|Dr*0_QtqO)qhoYr
> zB!|G6d!q^XuHb91phz(9?d|OJ>zuP%S^@x;xVZ^Kg68T}QbobcS>8YX`t at sbvy8lw
> zlarIR^-{5Z?VF`OCqW^hoiA^B_$NH6=GVlO5#Pr$MPgx~>>k%i_~O>QcNZkqB%Zeg
> z#mCc}370e-?Jg$0dxzWKPnYqRl#$5*l*GluGbhWKnwI7_^XURCU#rlt+_d8fULAJj
> z$`vF$ztTgK<B&YI(#t~#Ku}|2<B>&3rXvH3gzNm2Cx(KYocH$a8U4<f8v-X*e10bW
> z&d#yMzRLqhF7 at 2Ky**`wQ1H1k=IbdJQY}N8goMQ9`*e8gTXg$a(V~))Qr(MHdPvUy
> zfts#dD at DalY*$iWx|Ft#&absiyS-9KB$6obHJrOC_e(%!5Ver!#w7R*UgPGID6#2e
> zVXNLJcv|`K at o~$Z6m0j at zB9PWN>83NI?ob9IHaU}ds6O#frXIr+*lbZtgNhb at YxA?
> z4uwJ;G0o{tTmk~61qJYYjo|=4y@?u!32>ci9VSG(&!VED>b|2ti2K4V!>uxVC at CpH
> zsfHSM#K7V3A~nZ*7iIb>Z$jR}jtXCvy-J5o(*3}of17RpYYO_$`8p10XM6w1NK$Gl
> zkH at tcOSXGH^A+VyB8bz|)8OD>Q|${|^5UtNP2xOz5P&Jb^rvqOe^&3lJaCFXP=~{R
> zv<$e^Hnz4q+uOS3roqZkx9R&%%}2SrqP=ssk-cmeJD(~lDjFJ2fyvy#A0z=y;Ns?9
> z0T at dkVKJDif<M?~Xng;yb&S_5w6x{y7;}DB+hGa`@;kyNQL#x=gTKiMwbCXl=Ysae
> zAD$fgZES9ypKb;SI6lq}GXI&gEJM(HL&kv}F at v**DrYpRr7A(|?%_!i7KaC+ at gy5P
> z=0fXZl_At^V=k*UgN at UDm-@0tRu}s+WdqLq&K71rhvX?EcBXwdx5e<s$K95d581Dl
> ze!AL*M>rB~T2b=-^pnY0g~g+2maC1i{cXR`bHBqke={--#3&d3=9_hQId-wRs_6wI
> zt0WMhO+Z<IrU%6W at dsKTX2=xzx~i&*PrqiXOF}|od3pJyV(XsTYA+>o`UOm%Uwuwa
> z&YL%HYNvfx54Y!N!sh4E3A(zv6ciKy6ikzd%<lhRVmu>@7li;sBTp7Kj#h(0=10rT
> zz_~e9(|!ul;Y^qlzi}foG&J=1*hgLofS<d&NWeB3EMKp9A<y8oN<j1+Zf%VA`t=X+
> zd~O~d5(pn3pNosj+1VKooRTSRryLFLCotG>iD9GTR72nuDsDQ`avt^|YWZ1<<KyGD
> z&z~C`8t6znz`kE2Rq*umR9220v!_2!?pf&U?ELWI_SpiErow`P+eiihBZCTa66Cjq
> zr}|*>u!uW<vKGmZaD$47B*F{&t$}iq69sA&R at a*WJ_jU|a4;IBk}L?hdDHBYXWBhq
> zT$A_i+61d*`{h<Sp%4qOVW3U*oBbq^B3xWHc-%UGszvSP|26iqjY>zXMG^-nm_^fM
> z12XjPy~CZ7K;(Ztauh;zTZ_P96hs%}k6?=Ly2r=$!2H)LTwPhQ*McCFdHDI+#2gJ=
> zT<#z>3Wu6;<92zf>EE?4|NV56HDMNWEGj86s&j?}sOwl at FvmtG6^hwh{QRO!Q3?tQ
> zN((%UazbEI0!|qI_6>9t5}m;5>EWSQsvv~$IM^_h|2198^EMK&gKK?S=HP8)qvvLZ
> zxXXJOa=h9uY5(GIfB#iFIt?SEUJRYq*g>t@!cd{MnVA{Z)!WF3?Z?t%yAu-=S*1L-
> zy1c!;!KgZ^_}qdwz at dIB`HJPGkH9jt94hGQB1%g)uRGFfFEOQ{46?{JQ^YT$TwLp$
> z8XA1;%}Ay%qTNZ;!am&w#QqQdyp*84*IxAec%%jN<f7BrZsz&g`no>=^I*!$moJx>
> zm$PeL>HXQfLX|!4gGNDHoBXQ44X~U at YSVI^_t`%l3VhUQgjSV~KZ%KHLldsb^U5j^
> z9|1UbcxlHdeUVK=jGBezBo%Ygxo{5-s?}yNS2uI`XHH;%F3LLS1w0=yEvKWSGilq?
> z at G_VR{1bK0K at g6gea72^mbbUQHc&kOaYT_**PY0`yt$dA#9>*f%b!$gP!C^o)%i9t
> z;XB)Qc{pRJ1wXY3X2UIyYXn>Bz*LqV_t>QM5SA?+S-q;LsL<ek8;T@|oNo5Vv){a_
> zU95M at 0}@2NgOWYl4!QC2`j~%ai!2UIJe5ot|40}i^%Zq(W`wl&4p2!F2squ7Bz}J+
> z{<}T>KbPYFhuY`T>KenR?s~Ggt!aFBh*d`Yfv%)HA<+(g^w5wT?G6%-{H(0k)UJTp
> z!XCQr%s-Y_dhp<)9fQziwP15eD97&K1VUB?igJ;WkpUKKe}6wHHa9nSY03I5Y4<kL
> zwmK!#^|I)xMD#?Zm70mkFEC_5Q4vQFkgxWRjw3vNadB~C#0}7$gxf+SvzTgfV~KG~
> zMr^F$%ag;gN-IpAOCV-}Gt=+=)7$d$@<3b2NJ$f6*qp}+1%-u2)j(c=$N;GUf<sw*
> zpLnd%)9LBc*e(5Z(eoWL%8=<Qn}p0v%%}|MePRg4|6r=nsAxD4tTH$x#Ph`qF1qkM
> zwM=fhaNwl?h*ysB?%hf40h9XKvu7tgZ+Wx<l0Ab77&X<IqiJAVkanNcVbJ(jC|LxV
> zqO5w;NGK?fiMAps at 87crw*E3?>#(83l at 5}T#ms=|krB=+YZ0bmt%<?G>>*oP8k$1~
> z+iJb+elOgbuCcN4a|vGFNMjy*<LrL%NkXK1TM)^uTelRm<65{hObz2dXLWt~QbZN4
> z1659rjf;bLT$3dwBb)nt_h%ltn+Sm_`>_g#i5foR<}`RpVq%p)9=E?bvRep%(aWn&
> zgZoyH5(iE5v(k~>zQf;CD|H=!P0-?<AEdtREqI+AhfYMB1M8X_yonhc1Odf*txcuB
> zd}x_JLV3ZNEOFrGqv$65M&s+(uR)XUT}Hc$@6F82C`Iq+>?WIkx5ov?$H(I~F`3E9
> zO2oQNUfY>xdz`ZxqO!8*5dzIi8yh9X#dlMC{LIYF=ZkbJ&v3OZQ_cRMje>_$T}Lqs
> zNlm7vreD5%@$vP2^5n^SL|8-w4;L5cz1n3b5vCt%(b?WU>NI$k)E2b9d&=qvRD5m+
> z+qKx6&cn-F)m*9!oiir#?PonY_cU31-dpAJ4_as-j+*%4hQnwzxre~?2^}&Y_y;L$
> zW at z!-Ul|%5)u}hgNJ at INw$MF1JRB5s>1?d87St)&Lxgf}zcu*p1?SY^uAtbaCh2+u
> zHemGkS2RQPe>s;5^EurgIoO!8`<M=3`WTPj6$@e0Ghh?8Vn>*v?M3tQ@~FtkLk&YO
> zt_7j;rJ)G%i;Ti7C^U9wWyKbhLb=_A+7R<-Mq7WPHnz^Li_Bh^iT^9j|DPtM{XFL{
> z7e0NuudSUV47=djF3Xq*LyiW6NML+o0>3r;V3FbuXiySbsJIip=FO4a7J!SALXuba
> z^lKe04n}5x>Rn at ImhzAy+pzt!E4ksf^?Ee8uI<yOPe2$Agol4kK%}Hd)*xR=9j{gP
> z$v=1iI=h{}{Ti6s2Je)c2rvC{nENj!FispjFYegw>qC`*o?k01&dbeBQHJJGUU)#u
> ziAaP$>wF;~aBQ4kPyoyBr<VVxs`$~JujLeM)ALHexNV`p9TXK5xK5W)0LA(HD4B6;
> zqwZ!}PebNktsCf!L$X{}*_Q_FacR=t at zeufzs9DeoeWer0j1wPe*zo;n~a~1weg?*
> z9FOOh6xBSyI1SFT@?bQps6?se-OQd~^_-tHFVHB!;c#w?y)G;VJz|*2mH=4}jv$>L
> zA{G=NR!%{|r%1S_mex)bSk-Uf<<|uy0q72}RI<Rq0mvXPx3FVD`R|}PNrTxrIC8+W
> z`sJ7V`5LMzB99L<-~NsAjv20*Vb+b$kG1XXd5zgxZUV9Z=6mnpASNcp$<dLmcM0cN
> z&X|r7Lb>41x5dQ79w{o)6mqVXo1t7?T~*V><ydYF&gxA^G777vODYfplcxlS$A4vG
> zWc0><d8_SThYJ5|Ecv$_{nsTA)W?qlntUJ#mrUz@{P-~gzkw1A_NA}SxWXJHR&(d4
> znDg!P!fjUK|E0oM=DSQP&z{A#ntZjb_EU>e1d8kH<5Q*QATQrWtzV-^+;3a0nEfLW
> z1Tfv^s-u(q6=g3fCMx<PJo#`P?+7-Q7x30~a==@D-r&ZB03YA_>Z+9gvAdt&iL+vD
> zOT_6?+p`Mb&{Uwb$g0v(0cq(bkU(ZVmG(c@$a?DT>4|D at 2gI6Gf~^ez90?>OqGJa)
> z;e-KU!*v&D=cn9nDHkE{y0A=9mg4t}hrnVMdr~<kS$Z}i-&*x$T-7!l8mLGAeh?$8
> zlDi*=WiS^)^jqg7GLaKCKeGnpAJ>I_U_WMwDH3xOj{W<a0Xy$a*BZx?#9p3w%?j at L
> z8%Z{t8m{4+mcp*FuuM)(^#}-nP#KVKSCT+pBJ|cR2TZg7>G8gNU)IRZgmJm4f`^9(
> z3>Lm0`WLq?-ax^5tFop>3&8ErN<)KWmP>o1u$D9 at 0u^)PV0Rb4H>k#i1Ydg>9Iq6X
> zE~zEh7?QU90*E{!0_=w%*EZh?ucX~@5v0bx(&+*3mA^yaaZWj%n$6BW#4xreRjjnC
> z>YIrmd4M~<ar7V#Z4SI$nQQ^TA_qsug`|jx2viiawt;~%7s#qgKjOyo)$@Wf9+YAq
> z)q8ETL*~Jqr0SBa`g(7G$+!m-Zi>H0&e5)(o#BfdyBkxD at ccdC>=FlXIFEdd at o(QA
> z8o%oX<`o!^FW4QR_08o-q(XN8uOQr4bOU+OU)KL4X8qnC#{JfIq{Q$6$6)gW-~~Xc
> zSl6S4o>bt8xsc~aeE~oQ2nh)fZ%U-~uWy=StU$5|hy|xs3ZnJ%S*if)XhFz4u(*i>
> zH8rC32EBcYpLOk8EV8hbeKJz6^Tez~Rvf~&ZdstBSx;PzjErn;xm%>aPciajBq&o2
> zV=%@#I at YHlv0dbplsi^-y$SL0LgM1$X&JqEsRX$a<ptu>{tYaMsFXPF+_?jikCGdP
> z+;8<-+}Fr^r)8Sx;w5P4G7||nKXXzL{1?&&kv2P~$tLfF79~b62~hoOW5NR7LVGw|
> zgMHCes2jLaC)M)=dp at VWn;$tnu4OE|O^^VQG;s6dj9?PjIyl at 4YDb|W3`19mTU_Qf
> zO4GVyW2w(-5d_2#FClRfqYH%p`aa)pqoGe$Y+`I|tiK;(%0<A|X<8n6*xZ+J1iXhI
> zZ}^2*cV1QM{@JF)%Xn?wUt=PWPJ`$B4K<#~HrpL{hvd3L!0lIp#|o+sOXN*{{vZCR
> Bvx)!!
>
> literal 0
> HcmV?d00001
>
> --
> 2.7.3
>
More information about the wayland-devel
mailing list