Merge remote-tracking branch 'whot/publican'

2025-11-03 09:01:42 -05:00 · 2012-02-29 11:54:36 -05:00 · 2012-02-29 11:54:36 -05:00 · 72f9fd0a57
commit 72f9fd0a57
parent b26774da5b 1070579d4b
20 changed files with 668 additions and 4 deletions
--- a/Makefile.am
+++ b/Makefile.am
@ -1,4 +1,4 @@
-SUBDIRS = src protocol
+SUBDIRS = src protocol doc
 ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
--- a/configure.ac
+++ b/configure.ac
@ -51,8 +51,13 @@ fi
 AC_PATH_PROG(XSLTPROC, xsltproc)
 AM_CONDITIONAL([HAVE_XSLTPROC], [test $XSLTPROC != ""])
 AC_PATH_PROG(PUBLICAN, publican)
 AM_CONDITIONAL([HAVE_PUBLICAN], [test $PUBLICAN != ""])
 AC_CONFIG_FILES([Makefile
 		 wayland-scanner.m4
 		 doc/Makefile
 		 doc/Wayland/Makefile
 		 src/Makefile
 		 src/wayland-server.pc
 		 src/wayland-client.pc
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@ -0,0 +1 @@
 SUBDIRS = Wayland
--- a/doc/Wayland/.gitignore
+++ b/doc/Wayland/.gitignore
@ -0,0 +1,2 @@
 Wayland
 en-US/Protocol.xml
--- a/doc/Wayland/Makefile.am
+++ b/doc/Wayland/Makefile.am
@ -0,0 +1,54 @@
 if HAVE_PUBLICAN
 noinst_DATA = Wayland
 publican_sources = \
 	$(srcdir)/en-US/Wayland.ent \
 	$(srcdir)/en-US/Architecture.xml \
 	$(srcdir)/en-US/Author_Group.xml \
 	$(srcdir)/en-US/Book_Info.xml \
 	$(srcdir)/en-US/Chapter.xml \
 	$(srcdir)/en-US/Preface.xml \
 	$(srcdir)/en-US/Wayland.xml \
 	$(srcdir)/en-US/Revision_History.xml \
 	$(srcdir)/en-US/images/icon.svg  \
 	$(srcdir)/en-US/images/wayland-architecture.png \
 	$(srcdir)/en-US/images/wayland.png  \
 	$(srcdir)/en-US/images/x-architecture.png
 # publican does not support out-of-tree builds and during make distcheck the
 # source tree is read-only so we can't chdir and/or dump the protocol there
 # copy the tree into _build, leaving a marker file to clean up after
 # distclean
 # See https://bugzilla.redhat.com/show_bug.cgi?id=798484 for the chmod
 copy-sources:
 	if ! test -e "en-US/"; then \
 		mkdir en-US/; \
 		touch en-US/need-distclean; \
 		cp -r $(srcdir)/en-US/* en-US; \
 		chmod u+w en-US/images; \
 	fi
 Wayland: docbook-xsl publican.cfg $(publican_sources)
 	publican build --config=$(srcdir)/publican.cfg --lang en-US --format html,pdf
 # This must be run befor the publican run
 docbook-xsl: copy-sources $(top_srcdir)/protocol/wayland.xml $(srcdir)/protocol-to-docbook.xsl
 	$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-to-docbook.xsl $(top_srcdir)/protocol/wayland.xml > $(builddir)/en-US/Protocol.xml
 clean-local:
 	-rm -rf Wayland
 	if test -e "en-US/need-distclean"; then \
 		rm -rf en-US; \
 	fi
 install-data-local:
 	$(MKDIR_P) $(DESTDIR)$(docdir)
 	cp -R $(builddir)/Wayland $(DESTDIR)$(docdir)
 uninstall-local:
 	-rm -rf $(DESTDIR)$(docdir)/Wayland/*
 	-rmdir $(DESTDIR)$(docdir)/Wayland
 EXTRA_DIST = $(publican_sources) publican.cfg protocol-to-docbook.xsl
 endif
--- a/doc/Wayland/en-US/Architecture.xml
+++ b/doc/Wayland/en-US/Architecture.xml
@ -0,0 +1,318 @@
 <?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-Wayland-Architecture">
 	<title>Wayland Architecture</title>
 	<section id="sect-Wayland-Architecture-wayland_architecture">
 		<title>X vs. Wayland Architecture</title>
 		<para>
 			A good way to understand the wayland architecture
 			and how it is different from X is to follow an event
 			from the input device to the point where the change
 			it affects appears on screen.
 		</para>
 		<para>
 			This is where we are now with X:
 		</para>
 		<mediaobject>
 			<imageobject>
 				<imagedata fileref="images/x-architecture.png" format="PNG" />
 			</imageobject>
 		</mediaobject>
 		<para>
 			<orderedlist>
 				<listitem>
 					<para>
 						The kernel gets an event from an input
 						device and sends it to X through the evdev
 						input driver. The kernel does all the hard
 						work here by driving the device and
 						translating the different device specific
 						event protocols to the linux evdev input
 						event standard.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						The X server determines which window the
 						event affects and sends it to the clients
 						that have selected for the event in question
 						on that window. The X server doesn't
 						actually know how to do this right, since
 						the window location on screen is controlled
 						by the compositor and may be transformed in
 						a number of ways that the X server doesn't
 						understand (scaled down, rotated, wobbling,
 						etc).
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						The client looks at the event and decides
 						what to do. Often the UI will have to change
 						in response to the event - perhaps a check
 						box was clicked or the pointer entered a
 						button that must be highlighted. Thus the
 						client sends a rendering request back to the
 						X server.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						When the X server receives the rendering
 						request, it sends it to the driver to let it
 						program the hardware to do the rendering.
 						The X server also calculates the bounding
 						region of the rendering, and sends that to
 						the compositor as a damage event.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						The damage event tells the compositor that
 						something changed in the window and that it
 						has to recomposite the part of the screen
 						where that window is visible. The compositor
 						is responsible for rendering the entire
 						screen contents based on its scenegraph and
 						the contents of the X windows. Yet, it has
 						to go through the X server to render this.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						The X server receives the rendering requests
 						from the compositor and either copies the
 						compositor back buffer to the front buffer
 						or does a pageflip. In the general case, the
 						X server has to do this step so it can
 						account for overlapping windows, which may
 						require clipping and determine whether or
 						not it can page flip. However, for a
 						compositor, which is always fullscreen, this
 						is another unnecessary context switch.
 					</para>
 				</listitem>
 			</orderedlist>
 		</para>
 		<para>
 			As suggested above, there are a few problems with this
 			approach. The X server doesn't have the information to
 			decide which window should receive the event, nor can it
 			transform the screen coordinates to window local
 			coordinates. And even though X has handed responsibility for
 			the final painting of the screen to the compositing manager,
 			X still controls the front buffer and modesetting. Most of
 			the complexity that the X server used to handle is now
 			available in the kernel or self contained libraries (KMS,
 			evdev, mesa, fontconfig, freetype, cairo, Qt etc). In
 			general, the X server is now just a middle man that
 			introduces an extra step between applications and the
 			compositor and an extra step between the compositor and the
 			hardware.
 		</para>
 		<para>
 			In wayland the compositor is the display server. We transfer
 			the control of KMS and evdev to the compositor. The wayland
 			protocol lets the compositor send the input events directly
 			to the clients and lets the client send the damage event
 			directly to the compositor:
 		</para>
 		<mediaobject>
 			<imageobject>
 				<imagedata fileref="images/wayland-architecture.png" format="PNG" />
 			</imageobject>
 		</mediaobject>
 		<para>
 			<orderedlist>
 				<listitem>
 					<para>
 						The kernel gets an event and sends
 						it to the compositor. This
 						is similar to the X case, which is
 						great, since we get to reuse all the
 						input drivers in the kernel.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						The compositor looks through its
 						scenegraph to determine which window
 						should receive the event. The
 						scenegraph corresponds to what's on
 						screen and the compositor
 						understands the transformations that
 						it may have applied to the elements
 						in the scenegraph. Thus, the
 						compositor can pick the right window
 						and transform the screen coordinates
 						to window local coordinates, by
 						applying the inverse
 						transformations. The types of
 						transformation that can be applied
 						to a window is only restricted to
 						what the compositor can do, as long
 						as it can compute the inverse
 						transformation for the input events.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						As in the X case, when the client
 						receives the event, it updates the
 						UI in response. But in the wayland
 						case, the rendering happens in the
 						client, and the client just sends a
 						request to the compositor to
 						indicate the region that was
 						updated.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						The compositor collects damage
 						requests from its clients and then
 						recomposites the screen. The
 						compositor can then directly issue
 						an ioctl to schedule a pageflip with
 						KMS.
 					</para>
 				</listitem>
 			</orderedlist>
 		</para>
 	</section>
 	<section id="sect-Wayland-Architecture-wayland_rendering">
 		<title>Wayland Rendering</title>
 		<para>
 			One of the details I left out in the above overview
 			is how clients actually render under wayland. By
 			removing the X server from the picture we also
 			removed the mechanism by which X clients typically
 			render. But there's another mechanism that we're
 			already using with DRI2 under X: direct rendering.
 			With direct rendering, the client and the server
 			share a video memory buffer. The client links to a
 			rendering library such as OpenGL that knows how to
 			program the hardware and renders directly into the
 			buffer. The compositor in turn can take the buffer
 			and use it as a texture when it composites the
 			desktop. After the initial setup, the client only
 			needs to tell the compositor which buffer to use and
 			when and where it has rendered new content into it.
 		</para>
 		<para>
 			This leaves an application with two ways to update its window contents:
 		</para>
 		<para>
 			<orderedlist>
 				<listitem>
 					<para>
 						Render the new content into a new buffer and tell the compositor
 						to use that instead of the old buffer. The application can
 						allocate a new buffer every time it needs to update the window
 						contents or it can keep two (or more) buffers around and cycle
 						between them. The buffer management is entirely under
 						application control.
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						Render the new content into the buffer that it previously
 						told the compositor to to use. While it's possible to just
 						render directly into the buffer shared with the compositor,
 						this might race with the compositor. What can happen is that
 						repainting the window contents could be interrupted by the
 						compositor repainting the desktop. If the application gets
 						interrupted just after clearing the window but before
 						rendering the contents, the compositor will texture from a
 						blank buffer. The result is that the application window will
 						flicker between a blank window or half-rendered content. The
 						traditional way to avoid this is to render the new content
 						into a back buffer and then copy from there into the
 						compositor surface. The back buffer can be allocated on the
 						fly and just big enough to hold the new content, or the
 						application can keep a buffer around. Again, this is under
 						application control.
 					</para>
 				</listitem>
 			</orderedlist>
 		</para>
 		<para>
 			In either case, the application must tell the compositor
 			which area of the surface holds new contents. When the
 			application renders directly the to shared buffer, the
 			compositor needs to be noticed that there is new content.
 			But also when exchanging buffers, the compositor doesn't
 			assume anything changed, and needs a request from the
 			application before it will repaint the desktop. The idea
 			that even if an application passes a new buffer to the
 			compositor, only a small part of the buffer may be
 			different, like a blinking cursor or a spinner.
 			Hardware Enabling for Wayland
 		</para>
 		<para>
 			Typically, hardware enabling includes modesetting/display
 			and EGL/GLES2. On top of that Wayland needs a way to share
 			buffers efficiently between processes. There are two sides
 			to that, the client side and the server side.
 		</para>
 		<para>
 			On the client side we've defined a Wayland EGL platform. In
 			the EGL model, that consists of the native types
 			(EGLNativeDisplayType, EGLNativeWindowType and
 			EGLNativePixmapType) and a way to create those types. In
 			other words, it's the glue code that binds the EGL stack and
 			its buffer sharing mechanism to the generic Wayland API. The
 			EGL stack is expected to provide an implementation of the
 			Wayland EGL platform. The full API is in the wayland-egl.h
 			header. The open source implementation in the mesa EGL stack
 			is in wayland-egl.c and platform_wayland.c.
 		</para>
 		<para>
 			Under the hood, the EGL stack is expected to define a
 			vendor-specific protocol extension that lets the client side
 			EGL stack communicate buffer details with the compositor in
 			order to share buffers. The point of the wayland-egl.h API
 			is to abstract that away and just let the client create an
 			EGLSurface for a Wayland surface and start rendering. The
 			open source stack uses the drm Wayland extension, which lets
 			the client discover the drm device to use and authenticate
 			and then share drm (GEM) buffers with the compositor.
 		</para>
 		<para>
 			The server side of Wayland is the compositor and core UX for
 			the vertical, typically integrating task switcher, app
 			launcher, lock screen in one monolithic application. The
 			server runs on top of a modesetting API (kernel modesetting,
 			OpenWF Display or similar) and composites the final UI using
 			a mix of EGL/GLES2 compositor and hardware overlays if
 			available. Enabling modesetting, EGL/GLES2 and overlays is
 			something that should be part of standard hardware bringup.
 			The extra requirement for Wayland enabling is the
 			EGL_WL_bind_wayland_display extension that lets the
 			compositor create an EGLImage from a generic Wayland shared
 			buffer. It's similar to the EGL_KHR_image_pixmap extension
 			to create an EGLImage from an X pixmap.
 		</para>
 		<para>
 			The extension has a setup step where you have to bind the
 			EGL display to a Wayland display. Then as the compositor
 			receives generic Wayland buffers from the clients (typically
 			when the client calls eglSwapBuffers), it will be able to
 			pass the struct wl_buffer pointer to eglCreateImageKHR as
 			the EGLClientBuffer argument and with EGL_WAYLAND_BUFFER_WL
 			as the target. This will create an EGLImage, which can then
 			be used by the compositor as a texture or passed to the
 			modesetting code to use as an overlay plane. Again, this is
 			implemented by the vendor specific protocol extension, which
 			on the server side will receive the driver specific details
 			about the shared buffer and turn that into an EGL image when
 			the user calls eglCreateImageKHR.
 		</para>
 	</section>
 </chapter>
--- a/doc/Wayland/en-US/Author_Group.xml
+++ b/doc/Wayland/en-US/Author_Group.xml
@ -0,0 +1,16 @@
 <?xml version='1.0' encoding='utf-8' ?>
 <!DOCTYPE authorgroup 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;
 ]>
 <authorgroup>
 	<author>
 		<firstname>Kristian</firstname>
 		<surname>Høgsberg</surname>
 		<affiliation>
 			<orgname>Intel Corporation</orgname>
 		</affiliation>
 		<email>krh@bitplanet.net</email>
 	</author>
 </authorgroup>
--- a/doc/Wayland/en-US/Book_Info.xml
+++ b/doc/Wayland/en-US/Book_Info.xml
@ -0,0 +1,34 @@
 <?xml version='1.0' encoding='utf-8' ?>
 <!DOCTYPE bookinfo 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;
 ]>
 <bookinfo id="book-Wayland-Wayland">
 	<title>Wayland</title>
 	<subtitle>The Wayland display server</subtitle>
 	<productname>Documentation</productname>
 	<productnumber>0.1</productnumber>
 	<edition>0</edition>
 	<pubsnumber>0</pubsnumber>
 	<abstract>
 		<para>
 			Wayland is a protocol for a compositor to talk to
 			its clients as well as a C library implementation of
 			that protocol. The compositor can be a standalone
 			display server running on Linux kernel modesetting
 			and evdev input devices, an X application, or a
 			wayland client itself. The clients can be
 			traditional applications, X servers (rootless or
 			fullscreen) or other display servers.
 		</para>
 	</abstract>
 	<corpauthor>
 		<inlinemediaobject>
 			<imageobject>
 				<imagedata fileref="images/wayland.png" format="PNG" />
 			</imageobject>
 		</inlinemediaobject>
 	</corpauthor>
 	<xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 </bookinfo>
--- a/doc/Wayland/en-US/Chapter.xml
+++ b/doc/Wayland/en-US/Chapter.xml
@ -0,0 +1,32 @@
 <?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-Wayland-Test_Chapter">
 	<title>Test Chapter</title>
 	<para>
 		This is a test paragraph
 	</para>
 	<section id="sect-Wayland-Test_Chapter-Test_Section_1">
 		<title>Test Section 1</title>
 		<para>
 			This is a test paragraph in a section
 		</para>
 	</section>
 	<section id="sect-Wayland-Test_Chapter-Test_Section_2">
 		<title>Test Section 2</title>
 		<para>
 			This is a test paragraph in Section 2
 			<orderedlist>
 				<listitem>
 					<para>
 						listitem text
 					</para>
 				</listitem>
 			</orderedlist>
 		</para>
 	</section>
 </chapter>
--- a/doc/Wayland/en-US/Preface.xml
+++ b/doc/Wayland/en-US/Preface.xml
@ -0,0 +1,12 @@
 <?xml version='1.0' encoding='utf-8' ?>
 <!DOCTYPE preface 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;
 ]>
 <preface id="pref-Wayland-Preface">
 	<title>Preface</title>
 	<xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"><xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	</xi:fallback>
 	</xi:include>
 </preface>
--- a/doc/Wayland/en-US/Revision_History.xml
+++ b/doc/Wayland/en-US/Revision_History.xml
@ -0,0 +1,26 @@
 <?xml version='1.0' encoding='utf-8' ?>
 <!DOCTYPE appendix 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;
 ]>
 <appendix id="appe-Wayland-Revision_History">
 	<title>Revision History</title>
 	<simpara>
 		<revhistory>
 			<revision>
 				<revnumber>0-0</revnumber>
 				<date>Thu Feb 23 2012</date>
 				<author>
 					<firstname>Dude</firstname>
 					<surname>McPants</surname>
 					<email>Dude.McPants@example.com</email>
 				</author>
 				<revdescription>
 					<simplelist>
 						<member>Initial creation of book by publican</member>
 					</simplelist>
 				</revdescription>
 			</revision>
 		</revhistory>
 	</simpara>
 </appendix>
--- a/doc/Wayland/en-US/Wayland.ent
+++ b/doc/Wayland/en-US/Wayland.ent
@ -0,0 +1,4 @@
 <!ENTITY PRODUCT "Documentation">
 <!ENTITY BOOKID "Wayland">
 <!ENTITY YEAR "2012">
 <!ENTITY HOLDER "Kristian Høgsberg, Intel Corporation">
--- a/doc/Wayland/en-US/Wayland.xml
+++ b/doc/Wayland/en-US/Wayland.xml
@ -0,0 +1,19 @@
 <?xml version='1.0' encoding='utf-8' ?>
 <!DOCTYPE book 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;
 ]>
 <book>
 	<xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<!--
 	<xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Chapter.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="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	-->
 	<index />
 </book>
--- a/doc/Wayland/en-US/images/icon.svg
+++ b/doc/Wayland/en-US/images/icon.svg
@ -0,0 +1,19 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0" width="32" height="32" id="svg3017">
  <defs id="defs3019">
    <linearGradient id="linearGradient2381">
      <stop id="stop2383" style="stop-color:#ffffff;stop-opacity:1" offset="0"/>
      <stop id="stop2385" style="stop-color:#ffffff;stop-opacity:0" offset="1"/>
    </linearGradient>
    <linearGradient x1="296.4996" y1="188.81061" x2="317.32471" y2="209.69398" id="linearGradient2371" xlink:href="#linearGradient2381" gradientUnits="userSpaceOnUse" gradientTransform="matrix(0.90776,0,0,0.90776,24.35648,49.24131)"/>
  </defs>
  <g transform="matrix(0.437808,-0.437808,0.437808,0.437808,-220.8237,43.55311)" id="g5089">
    <path d="m 8.4382985,-6.28125 c -0.6073916,0 -4.3132985,5.94886271 -4.3132985,8.25 l 0,26.71875 c 0,0.846384 0.5818159,1.125 1.15625,1.125 l 25.5625,0 c 0.632342,0 1.125001,-0.492658 1.125,-1.125 l 0,-5.21875 0.28125,0 c 0.49684,0 0.906249,-0.409411 0.90625,-0.90625 l 0,-27.9375 c 0,-0.4968398 -0.40941,-0.90625 -0.90625,-0.90625 l -23.8117015,0 z" transform="translate(282.8327,227.1903)" id="path5091" style="fill:#5c5c4f;stroke:#000000;stroke-width:3.23021388;stroke-miterlimit:4;stroke-dasharray:none"/>
    <rect width="27.85074" height="29.369793" rx="1.1414107" ry="1.1414107" x="286.96509" y="227.63805" id="rect5093" style="fill:#032c87"/>
    <path d="m 288.43262,225.43675 25.2418,0 0,29.3698 -26.37615,0.0241 1.13435,-29.39394 z" id="rect5095" style="fill:#ffffff"/>
    <path d="m 302.44536,251.73726 c 1.38691,7.85917 -0.69311,11.28365 -0.69311,11.28365 2.24384,-1.60762 3.96426,-3.47694 4.90522,-5.736 0.96708,2.19264 1.83294,4.42866 4.27443,5.98941 0,0 -1.59504,-7.2004 -1.71143,-11.53706 l -6.77511,0 z" id="path5097" style="fill:#a70000;fill-opacity:1;stroke-width:2"/>
    <rect width="25.241802" height="29.736675" rx="0.89682275" ry="0.89682275" x="290.73544" y="220.92249" id="rect5099" style="fill:#809cc9"/>
    <path d="m 576.47347,725.93939 6.37084,0.41502 0.4069,29.51809 c -1.89202,-1.31785 -6.85427,-3.7608 -8.26232,-1.68101 l 0,-26.76752 c 0,-0.82246 0.66212,-1.48458 1.48458,-1.48458 z" transform="matrix(0.499065,-0.866565,0,1,0,0)" id="rect5101" style="fill:#4573b3;fill-opacity:1"/>
    <path d="m 293.2599,221.89363 20.73918,0 c 0.45101,0 0.8141,0.3631 0.8141,0.81411 0.21547,6.32836 -19.36824,21.7635 -22.36739,17.59717 l 0,-17.59717 c 0,-0.45101 0.3631,-0.81411 0.81411,-0.81411 z" id="path5103" style="opacity:0.65536726;fill:url(#linearGradient2371);fill-opacity:1"/>
  </g>
 </svg>
--- a/doc/Wayland/en-US/images/wayland-architecture.png
+++ b/doc/Wayland/en-US/images/wayland-architecture.png
--- a/doc/Wayland/en-US/images/wayland.png
+++ b/doc/Wayland/en-US/images/wayland.png
--- a/doc/Wayland/en-US/images/x-architecture.png
+++ b/doc/Wayland/en-US/images/x-architecture.png
--- a/doc/Wayland/protocol-to-docbook.xsl
+++ b/doc/Wayland/protocol-to-docbook.xsl
@ -0,0 +1,113 @@
 <?xml version="1.0" ?>
 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output method="xml" indent="yes" encoding="UTF-8"/>
 <xsl:output method="xml" encoding="UTF-8" indent="yes" />
 <xsl:template match="/">
  <!-- insert docbook's DOCTYPE blurb -->
    <xsl:text disable-output-escaping = "yes"><![CDATA[
 <!DOCTYPE appendix 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;
 ]>
 ]]></xsl:text>
  <appendix id="appe-Wayland-Protocol">
    <title>Wayland Protocol Specification</title>
    <xsl:apply-templates select="protocol/copyright" />
    <xsl:apply-templates select="protocol/interface" />
  </appendix>
 </xsl:template>
 <!-- Copyright blurb -->
 <xsl:template match="copyright">
  <para>
    <literallayout>
      <xsl:value-of select="." disable-output-escaping="yes"/>
    </literallayout>
  </para>
 </xsl:template>
 <!-- Interface descriptions -->
 <xsl:template match="interface" >
  <section>
    <xsl:attribute name="id">protocol-<xsl:value-of select="name()"/>-<xsl:value-of select="@name" />
    </xsl:attribute>
    <title>
      <xsl:value-of select="@name" />
      <!-- only show summary if it exists -->
      <xsl:if test="description/@summary">
 	- <xsl:value-of select="description/@summary" />
      </xsl:if>
    </title>
    <para>
      <xsl:value-of select="description"/>
    </para>
    <xsl:if test="request">
      <section>
        <title>Requests provided by <xsl:value-of select="@name" /></title>
        <xsl:apply-templates select="request" />
      </section>
    </xsl:if>
    <xsl:if test="event">
      <section>
        <title>Events provided by <xsl:value-of select="@name" /> events</title>
        <xsl:apply-templates select="event" />
      </section>
    </xsl:if>
    <xsl:if test="enum">
      <section>
        <title>Enums provided by <xsl:value-of select="@name" /> enums</title>
      <xsl:apply-templates select="enum" />
      </section>
    </xsl:if>
  </section>
 </xsl:template>
 <!-- table contents for request/event arguments or enum values -->
 <xsl:template match="arg|entry">
  <varlistentry>
    <term><xsl:value-of select="@name"/></term>
    <listitem>
        <xsl:if test="name() = 'arg'" >
          <para>Type: <xsl:value-of select="@type"/></para>
        </xsl:if>
        <xsl:if test="name() = 'entry'" >
          <para>Value: <xsl:value-of select="@value"/></para>
        </xsl:if>
      <para>
        <xsl:value-of select="@summary"/>
      </para>
    </listitem>
  </varlistentry>
 </xsl:template>
 <!-- Request/event list -->
 <xsl:template match="request|event|enum">
  <section>
    <xsl:attribute name="id">protocol-interface-<xsl:value-of select="../@name"/>-<xsl:value-of select="name()"/>-<xsl:value-of select="@name"/></xsl:attribute>
    <title>
      <xsl:value-of select="../@name"/>::<xsl:value-of select="@name" />
      <xsl:if test="description/@summary">
        - <xsl:value-of select="description/@summary" />
      </xsl:if>
    </title>
    <para><xsl:value-of select="description"/></para>
    <xsl:if test="arg">
      <variablelist>
        <title><xsl:value-of select="../@name"/>::<xsl:value-of select="@name" /> arguments</title>
        <xsl:apply-templates select="arg"/>
      </variablelist>
    </xsl:if>
    <xsl:if test="entry">
      <variablelist>
        <title><xsl:value-of select="../@name"/>::<xsl:value-of select="@name" /> values</title>
          <xsl:apply-templates select="entry"/>
      </variablelist>
    </xsl:if>
  </section>
 </xsl:template>
 </xsl:stylesheet>
 <!-- vim: set expandtab shiftwidth=2: -->
--- a/doc/Wayland/publican.cfg
+++ b/doc/Wayland/publican.cfg
@ -0,0 +1,8 @@
 # Config::Simple 4.59
 # Fri Feb 24 09:36:50 2012
 xml_lang: "en-US"
 type: Book
 brand: common
 tmp_dir: Wayland
--- a/protocol/Makefile.am
+++ b/protocol/Makefile.am
@ -1,7 +1,8 @@
 if HAVE_XSLTPROC
-doc_DATA = wayland.html wayland-protocol.css
+dist_doc_DATA = wayland.html wayland-protocol.css wayland.xml
-wayland.html: wayland.xml protocol.xsl
+wayland.html: $(srcdir)/wayland.xml $(srcdir)/protocol.xsl
-	$(AM_V_GEN)$(XSLTPROC) protocol.xsl wayland.xml > $@
+	$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol.xsl $(srcdir)/wayland.xml > $@
 CLEANFILES = wayland.html
 endif
`@ -1,4 +1,4 @@`
	`SUBDIRS = src protocol`	`SUBDIRS = src protocol doc`

	`ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}`	`ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}`