>, URL="#impl"]
c1 -> xserver [taillabel="③", labeldistance=2, URL="#step_3"];
c2 -> xserver;
c3 -> xserver;
xserver -> c1 [taillabel="②", labeldistance=2, URL="#step_2"];
xserver -> c2;
xserver -> c3;
xserver -> impl [taillabel="⑥", labeldistance=1.75, URL="#step_6"];
xserver -> impl [style=invis, label=" "];
impl -> xserver [taillabel="①", labeldistance=1.75, URL="#step_1"];
xserver -> comp [style=invis];
xserver -> comp [taillabel="④", labeldistance=1.75, labelangle=-45, URL="#step_4"];
comp -> xserver [taillabel="⑤", URL="#step_5"];
comp -> xserver [style=invis]
c1 -> c2 [style=invis];
c3 -> c2 [style=invis];
}
wayland-1.16.0/doc/doxygen/mainpage.dox 0000664 0000000 0000000 00000001256 13254025114 014646 0 ustar /**
* @mainpage
* Wayland protocol API documentation.
*
* This documentation is available for the Server- and the Client-side APIs.
*
* - Server-side API
* - Client-side API
*
* Further documentation about the architecture and principles of Wayland is
* available in the
* Wayland Book
*
* @section ifaces Interfaces
* For the list of available interfaces, please see the
* modules list.
*
* @section protocols Protocols
* For the list of protocols, please see the
* Related Pages.
*
*/
wayland-1.16.0/doc/doxygen/wayland.doxygen.in 0000664 0000000 0000000 00000001373 13344007452 016021 0 ustar # Wayland-specific overrides
PROJECT_NAME = "Wayland"
PROJECT_NUMBER = @VERSION@
OUTPUT_DIRECTORY = @top_builddir@/doc/doxygen
JAVADOC_AUTOBRIEF = YES
TAB_SIZE = 8
QUIET = YES
HTML_TIMESTAMP = YES
GENERATE_LATEX = NO
MAN_LINKS = NO
PREDEFINED = WL_EXPORT= \
WL_PRINTF(x,y)=
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = YES
DOT_MULTI_TARGETS = YES
ALIASES += comment{1}="/* \1 */"
OPTIMIZE_OUTPUT_FOR_C = YES
EXTRACT_ALL = YES
EXTRACT_STATIC = YES
# These must be set in the Makefile
GENERATE_HTML = NO
GENERATE_XML = NO
GENERATE_MAN = NO
wayland-1.16.0/doc/man/ 0000775 0000000 0000000 00000000000 13344007452 011450 5 ustar wayland-1.16.0/doc/man/Makefile.am 0000664 0000000 0000000 00000002437 12663124406 013514 0 ustar #
# This generates man-pages out of the Docbook XML files. Simply add your files
# to the $MANPAGES array. If aliases are created, please add them to the
# MANPAGES_ALIASES array so they get installed correctly.
#
MANPAGES = \
wl_display_connect.3
MANPAGES_ALIASES = \
wl_display_connect_to_fd.3
XML_FILES = \
${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst %.5,%.xml,${patsubst %.7,%.xml,$(MANPAGES)}}}}
CLEANFILES =
EXTRA_DIST = $(XML_FILES)
if HAVE_XSLTPROC
if HAVE_MANPAGES_STYLESHEET
CLEANFILES += $(MANPAGES) $(MANPAGES_ALIASES)
EXTRA_DIST += $(MANPAGES) $(MANPAGES_ALIASES)
dist_man_MANS = $(MANPAGES) $(MANPAGES_ALIASES)
XSLTPROC_FLAGS = \
--stringparam man.authors.section.enabled 0 \
--stringparam man.copyright.section.enabled 0 \
--stringparam funcsynopsis.style ansi \
--stringparam man.output.quietly 1 \
--nonet
XSLTPROC_PROCESS_MAN = \
$(AM_V_GEN)$(MKDIR_P) $(dir $@) && \
$(XSLTPROC) -o $@ $(XSLTPROC_FLAGS) $(MANPAGES_STYLESHEET) $< && \
$(SED) -i -e 's/^\.so \(.*\)\.\(.\)$$/\.so man\2\/\1\.\2/' $(MANPAGES_ALIASES)
%.1: %.xml
$(XSLTPROC_PROCESS_MAN)
%.3: %.xml
$(XSLTPROC_PROCESS_MAN)
%.5: %.xml
$(XSLTPROC_PROCESS_MAN)
%.7: %.xml
$(XSLTPROC_PROCESS_MAN)
wl_display_connect_to_fd.3: wl_display_connect.3
endif # HAVE_MANPAGES_STYLESHEET
endif # HAVE_XSLTPROC
wayland-1.16.0/doc/man/wl_display_connect.xml 0000664 0000000 0000000 00000011023 13344007452 016047 0 ustar
wl_display_connectwayland-clientSeptember 2012DeveloperDavidHerrmanndh.herrmann@googlemail.comwl_display_connect3wl_display_connectwl_display_connect_to_fdConnect to a Wayland socket#include <wayland-client.h>struct wl_display *wl_display_connectconst char *namestruct wl_display *wl_display_connect_to_fdint fdDescriptionwl_display_connect connects to a Wayland socket
that was previously opened by a Wayland server. The server socket must
be placed in XDG_RUNTIME_DIR when WAYLAND_DISPLAY
(or name, see below) is a simple name, for this
function to find it. The server socket is also allowed to exist at an
arbitrary path; usage details follow. See below for compatibility issue
details.The name argument specifies the name of
the socket or NULL to use the default (which is
"wayland-0"). The environment variable
WAYLAND_DISPLAY replaces the default value.
If name is an absolute path, then that path is used
as the Wayland socket to which the connection is attempted. Note that
in combination with the default-value behavior described above, this
implies that setting WAYLAND_DISPLAY to an absolute
path will implicitly cause name to take on that
absolute path if name is NULL.
If WAYLAND_SOCKET is set, this function behaves like
wl_display_connect_to_fd with the file-descriptor
number taken from the environment variable.Support for interpreting WAYLAND_DISPLAY as an
absolute path is a change in behavior compared to
wl_display_connect's behavior in versions
1.14 and older of Wayland. It is no longer guaranteed in versions
1.15 and higher that the Wayland socket chosen is equivalent to
manually constructing a socket pathname by concatenating
XDG_RUNTIME_DIR and WAYLAND_DISPLAY.
Manual construction of the socket path must account for the
possibility that WAYLAND_DISPLAY contains an absolute
path.wl_display_connect_to_fd connects to a Wayland
socket with an explicit file-descriptor. The file-descriptor is passed
as argument fd.Return Valuewl_display_connect and
wl_display_connect_to_fd return a new display
context object or NULL on failure. errno is set
correspondingly.See Alsowayland-client7,
wl_display_disconnect3,
wl_display_iterate3
wayland-1.16.0/doc/publican/ 0000775 0000000 0000000 00000000000 13344007452 012472 5 ustar wayland-1.16.0/doc/publican/Makefile.am 0000664 0000000 0000000 00000014541 13344007452 014533 0 ustar # Documentation is built with xmlto, but some of the recipes in here are
# leftovers from building with Publican (https://fedorahosted.org/publican/)
#
# How this build works:
# * the main target is Wayland, documentation ends up in $(builddir)/Wayland/
# * hand-written chapters and CSS files are located in sources. These are
# copied into $(builddir)/en-US/
# * ProtocolSpec.xml is generated from $(top_srcdir)/protocol/wayland.xml,
# changed into docbook via XSLT and saved in $(builddir)/en-US/
# * ProtocolInterfaces.xml, same as above, uses a different XSLT
# * *API.xml is generated from the doxygen output and saved in
# $(builddir)/en-US
# * run xmlto on $(builddir)/en-US, output to $(builddir)/Wayland/en-US
doxydir := $(top_builddir)/doc/doxygen
html_destdir := $(builddir)/Wayland/en-US/html
publican_sources = \
$(srcdir)/sources/Wayland.ent \
$(srcdir)/sources/Wayland.xml \
$(srcdir)/sources/Book_Info.xml \
$(srcdir)/sources/Author_Group.xml \
$(srcdir)/sources/Foreword.xml \
$(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
processed_sources := \
$(srcdir)/sources/Architecture.xml \
$(srcdir)/sources/Introduction.xml
css_sources = \
$(srcdir)/sources/css/brand.css \
$(srcdir)/sources/css/common.css \
$(srcdir)/sources/css/default.css \
$(srcdir)/sources/css/epub.css \
$(srcdir)/sources/css/print.css
img_sources = \
$(srcdir)/sources/images/icon.svg \
$(srcdir)/sources/images/wayland.png \
$(srcdir)/sources/images/xwayland-architecture.png
doxygen_img_sources := \
$(doxydir)/xml/wayland-architecture.png \
$(doxydir)/xml/x-architecture.png
map_sources := \
$(doxydir)/xml/x-architecture.map \
$(doxydir)/xml/wayland-architecture.map
if HAVE_XMLTO
if HAVE_XSLTPROC
noinst_DATA = $(builddir)/Wayland $(publican_targets)
XMLTO_PARAM = \
--skip-validation \
--stringparam chunk.section.depth=0 \
--stringparam toc.section.depth=1 \
--stringparam html.stylesheet=css/default.css
# Listing various directories that might need to be created.
alldirs := $(builddir)/en-US $(builddir)/en-US/images $(html_destdir) $(html_destdir)/css $(html_destdir)/images
html_css_targets = $(addprefix $(html_destdir)/css/,$(notdir $(css_sources)))
html_img_targets = $(addprefix $(html_destdir)/images/,$(notdir $(img_sources)))
doxygen_img_targets := $(doxygen_img_sources:$(doxydir)/xml/%=$(html_destdir)/images/%)
map_targets := $(map_sources:$(doxydir)/xml/%=$(builddir)/en-US/images/%)
processed_targets := $(processed_sources:$(srcdir)/sources/%=$(builddir)/en-US/%)
$(builddir)/Wayland: $(publican_targets) $(html_css_targets) $(html_img_targets) $(processed_targets) $(doxygen_img_targets) | $(builddir)/en-US
$(AM_V_GEN)$(XMLTO) $(XMLTO_PARAM) html $(builddir)/en-US/Wayland.xml -o $(html_destdir)
@touch $@
$(html_destdir)/css/%: $(srcdir)/sources/css/% | $(html_destdir)/css
$(AM_V_GEN)cp -f $< $@
$(html_destdir)/images/%: $(srcdir)/sources/images/% | $(html_destdir)/images
$(AM_V_GEN)cp -f $< $@
$(html_destdir)/images/%: $(doxydir)/xml/% | $(html_destdir)/images
$(AM_V_GEN)cp -f $< $@
pubdir = $(docdir)/Wayland/en-US
publican_targets = $(publican_sources:$(srcdir)/sources/%=$(builddir)/en-US/%) \
$(builddir)/en-US/ProtocolSpec.xml \
$(builddir)/en-US/ProtocolInterfaces.xml \
$(builddir)/en-US/ClientAPI.xml \
$(builddir)/en-US/ServerAPI.xml
# The Protocol.xml is purely generated and required before running publican
$(builddir)/en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml $(srcdir)/protocol-to-docbook.xsl | $(builddir)/en-US
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-to-docbook.xsl \
$(top_srcdir)/protocol/wayland.xml > $@
$(builddir)/en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml $(srcdir)/protocol-interfaces-to-docbook.xsl | $(builddir)/en-US
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-interfaces-to-docbook.xsl \
$(top_srcdir)/protocol/wayland.xml > $@
# * use doxygen's combine.xslt to merge the xml files into one single file
# * pipe that through the doxygen-to-publican stylesheet
$(builddir)/en-US/%API.xml: $(doxydir)/xml/%/index.xml $(srcdir)/doxygen-to-publican.xsl | $(builddir)/en-US
$(AM_V_GEN)$(XSLTPROC) $(doxydir)/xml/$*/combine.xslt \
$(doxydir)/xml/$*/index.xml | \
$(XSLTPROC) --stringparam which $* \
$(srcdir)/doxygen-to-publican.xsl - > $@
# Copy the sources source files into en-US destination
# This is required for out-of-source-tree build as publican does not allow us
# to specify the location of the source code.
$(builddir)/en-US/%: $(srcdir)/sources/% $(publican_sources) | $(builddir)/en-US/images
$(AM_V_GEN)cp -f $< $@
$(AM_V_at)chmod a+w $@
$(builddir)/en-US/images/%: $(doxydir)/xml/% | $(builddir)/en-US/images
$(AM_V_GEN)cp -f $< $@
$(AM_V_at)chmod a+w $@
# More specific rule to override explicitly listed targets and perform xslt
# modifications on them.
# Note that we can't use $< as all targets must be there
$(processed_targets): $(processed_sources) $(map_targets) $(srcdir)/merge-mapcoords.xsl | $(builddir)/en-US/images
$(AM_V_GEN)$(XSLTPROC) --stringparam basedir $(builddir)/en-US \
$(srcdir)/merge-mapcoords.xsl $(addprefix $(srcdir)/sources/,$(notdir $@)) > $@
# general rule to create one of the listed directories.
$(alldirs):
$(AM_V_GEN)$(MKDIR_P) $@
CLEANFILES = $(publican_targets)
clean-local:
$(AM_V_at)rm -fr $(builddir)/en-US
$(AM_V_at)rm -fr $(builddir)/Wayland
install-data-local:
test -z "$(pubdir)/html/css" || $(mkdir_p) "$(DESTDIR)$(pubdir)/html/css"
test -z "$(pubdir)/html/images" || $(mkdir_p) "$(DESTDIR)$(pubdir)/html/images"
list=`find $(builddir)/Wayland/en-US -type f`; \
for p in $$list; do \
echo " $(INSTALL_DATA) '$$p' '$(DESTDIR)$(docdir)/$$p'"; \
$(INSTALL_DATA) "$$p" "$(DESTDIR)$(docdir)/$$p"; \
done;
uninstall-local:
@if test -n $(DESTDIR)$(docdir); then \
if test -d $(DESTDIR)$(docdir); then \
echo " rm -fr $(DESTDIR)$(docdir)/Wayland;"; \
rm -fr $(DESTDIR)$(docdir)/Wayland; \
fi; \
fi;
endif
endif
EXTRA_DIST = \
$(publican_sources) $(processed_sources) $(css_sources) $(img_sources) \
protocol-to-docbook.xsl \
protocol-interfaces-to-docbook.xsl \
doxygen-to-publican.xsl \
merge-mapcoords.xsl
wayland-1.16.0/doc/publican/doxygen-to-publican.xsl 0000664 0000000 0000000 00000010716 13254025114 017112 0 ustar
FunctionsReturns:
See also:
Since: Note:
-
-
wayland-1.16.0/doc/publican/merge-mapcoords.xsl 0000664 0000000 0000000 00000004412 12663124406 016311 0 ustar
%BOOK_ENTITIES;
]>
]]>
wayland-1.16.0/doc/publican/protocol-interfaces-to-docbook.xsl 0000664 0000000 0000000 00000003015 12663124406 021243 0 ustar
%BOOK_ENTITIES;
]>
]]>Interfaces
The protocol includes several interfaces which are used for
interacting with the server. Each interface provides requests,
events, and errors (which are really just special events) as described
above. Specific compositor implementations may have their own
interfaces provided as extensions, but there are several which are
always expected to be present.
Core interfaces:
wayland-1.16.0/doc/publican/protocol-to-docbook.xsl 0000664 0000000 0000000 00000015172 13254025114 017122 0 ustar
%BOOK_ENTITIES;
]>
]]>Wayland Protocol Specification
- Requests provided by Events provided by Enums provided by
-
-
-
id for the new
- ::::
()
- ::
- ::
- bitfield
-
wayland-1.16.0/doc/publican/sources/ 0000775 0000000 0000000 00000000000 13344007532 014154 5 ustar wayland-1.16.0/doc/publican/sources/Architecture.xml 0000664 0000000 0000000 00000033306 13254025114 017321 0 ustar
%BOOK_ENTITIES;
]>
Wayland ArchitectureX vs. Wayland Architecture
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.
This is where we are now with X:
X architecture diagram
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.
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).
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.
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.
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.
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.
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.
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:
Wayland architecture diagram
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.
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.
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.
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.
Wayland Rendering
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.
This leaves an application with two ways to update its window contents:
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.
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.
In either case, the application must tell the compositor
which area of the surface holds new contents. When the
application renders directly to the 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
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.
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.
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.
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.
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.
wayland-1.16.0/doc/publican/sources/Author_Group.xml 0000664 0000000 0000000 00000000726 12663124406 017324 0 ustar
%BOOK_ENTITIES;
]>
KristianHøgsbergIntel Corporationkrh@bitplanet.net
wayland-1.16.0/doc/publican/sources/Book_Info.xml 0000664 0000000 0000000 00000005071 13254025114 016542 0 ustar
%BOOK_ENTITIES;
]>
WaylandThe Wayland ProtocolDocumentation0.110
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.
Wayland logo
Copyright &YEAR; &HOLDER;
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
wayland-1.16.0/doc/publican/sources/Client.xml 0000664 0000000 0000000 00000010626 13254025114 016115 0 ustar
%BOOK_ENTITIES;
]>
Client APIIntroduction
The open-source reference implementation of Wayland protocol is
split in two C libraries, libwayland-client and libwayland-server. Their main
responsibility is to handle the Inter-process communication
(IPC) with each other, therefore guaranteeing
the protocol objects marshaling and messages synchronization.
A client uses libwayland-client to communicate with one or more
wayland servers. A wl_display object is
created and manages each open connection to a server. At least one
wl_event_queue
object is created for each wl_display, this holds events as they
are received from the server until they can be
processed. Multi-threading is supported by creating an additional
wl_event_queue for each additional thread, each object can have
it's events placed in a particular queue, so potentially a
different thread could be made to handle the events for each
object created.
Though some convenience functions are provided, libwayland-client
is designed to allow the calling code to wait for events, so that
different polling mechanisms can be used. A file descriptor is
provided, when it becomes ready for reading the calling code can
ask libwayland-client to read the available events from it into
the wl_event_queue objects.
The library only provides low-level access to the wayland objects.
Each object created by the client is represented by a wl_proxy object that this
library creates. This includes the id that is actually
communicated over the socket to the server, a void* data pointer
that is intended to point at a client's representation of the
object, and a pointer to a static wl_interface object,
which is generated from the xml and identifies the object's class
and can be used for introspection into the messages and events.
Messages are sent by calling wl_proxy_marshal. This will write a
message to the socket, by using the message id and the
wl_interface to identify the types of each argument and convert
them into stream format. Most software will call type-safe
wrappers generated from the xml description of the Wayland protocols. For
instance the C header file generated from the xml defines the
following inline function to transmit the wl_surface::attach
message:
static inline void
wl_surface_attach(struct wl_surface *wl_surface, struct wl_buffer *buffer, int32_t x, int32_t y)
{
wl_proxy_marshal((struct wl_proxy *) wl_surface, WL_SURFACE_ATTACH, buffer, x, y);
}
Events (messages from the server) are handled by calling a
"dispatcher" callback the client stores in the wl_proxy for each
event. A language binding for a string-based interpreter, such as
CPython, might have a dispatcher that uses the event name from the
wl_interface to identify the function to call. The default
dispatcher uses the message id number to index an array of
functions pointers, called a wl_listener, and the wl_interface to
convert data from the stream into arguments to the function. The
C header file generated from the xml defines a per-class structure
that forces the function pointers to be of the correct type, for
instance the wl_surface::enter
event defines this pointer in the wl_surface_listener object:
struct wl_surface_listener {
void (*enter)(void *data, struct wl_surface *, struct wl_output *);
...
}
&doxygen;
wayland-1.16.0/doc/publican/sources/Compositors.xml 0000664 0000000 0000000 00000011124 12663124406 017221 0 ustar
%BOOK_ENTITIES;
]>
Types of Compositors
Compositors come in different types, depending on which
role they play in the overall architecture of the OS.
For instance, a
system compositor
can be used for booting the system, handling multiple user switching, a
possible console terminal emulator and so forth. A different compositor, a
session compositor
would provide the actual desktop environment. There are many ways for
different types of compositors to co-exist.
In this section, we introduce three types of Wayland compositors relying
on libwayland-server.
System Compositor
A system compositor can run from early boot until shutdown.
It effectively replaces the kernel vt system, and can tie in
with the systems graphical boot setup and multiseat support.
A system compositor can host different types of session
compositors, and let us switch between multiple sessions
(fast user switching, or secure/personal desktop switching).
A linux implementation of a system compositor will typically
use libudev, egl, kms, evdev and cairo.
For fullscreen clients, the system compositor can reprogram the
video scanout address to read directly from the client provided
buffer.
Session Compositor
A session compositor is responsible for a single user session.
If a system compositor is present, the session compositor will
run nested under the system compositor. Nesting is feasible because
the protocol is asynchronous; roundtrips would be too expensive
when nesting is involved. If no system compositor is present, a
session compositor can run directly on the hw.
X applications can continue working under a session compositor
by means of a root-less X server that is activated on demand.
Possible examples for session compositors include
gnome-shell
moblin
kwin
kmscon
rdp session
Weston with X11 or Wayland backend is a session compositor nested
in another session compositor.
fullscreen X session under Wayland
Embedding Compositor
X11 lets clients embed windows from other clients, or lets clients
copy pixmap contents rendered by another client into their window.
This is often used for applets in a panel, browser plugins and similar.
Wayland doesn't directly allow this, but clients can communicate GEM
buffer names out-of-band, for example, using D-Bus, or command line
arguments when the panel launches the applet. Another option is to
use a nested Wayland instance. For this, the Wayland server will have
to be a library that the host application links to. The host
application will then pass the Wayland server socket name to the
embedded application, and will need to implement the Wayland
compositor interface. The host application composites the client
surfaces as part of it's window, that is, in the web page or in the
panel. The benefit of nesting the Wayland server is that it provides
the requests the embedded client needs to inform the host about buffer
updates and a mechanism for forwarding input events from the host
application.
An example for this kind of setup is firefox embedding the flash
player as a kind of special-purpose compositor.
wayland-1.16.0/doc/publican/sources/Foreword.xml 0000664 0000000 0000000 00000001615 12663124406 016473 0 ustar
%BOOK_ENTITIES;
]>
Preface
This document describes the (i) Wayland architecture, (ii) Wayland model of
operation and (iii) its library API. Also, the Wayland protocol specification is shown
in the Appendix. This document is aimed primarily at Wayland developers and
those looking to program with it; it does not cover application development.
There have been many contributors to this document and since this is only the
first edition many errors are expected to be found. We appreciate
corrections.
Yours,
the Wayland open-source community
November 2012
wayland-1.16.0/doc/publican/sources/Introduction.xml 0000664 0000000 0000000 00000013054 12663124406 017365 0 ustar
%BOOK_ENTITIES;
]>
IntroductionMotivation
Most Linux and Unix-based systems rely on the X Window System (or
simply X) as the low-level protocol for building
bitmap graphics interfaces. On these systems, the X stack has grown to
encompass functionality arguably belonging in client libraries,
helper libraries, or the host operating system kernel. Support for
things like PCI resource management, display configuration management,
direct rendering, and memory management has been integrated into the X
stack, imposing limitations like limited support for standalone
applications, duplication in other projects (e.g. the Linux fb layer
or the DirectFB project), and high levels of complexity for systems
combining multiple elements (for example radeon memory map handling
between the fb driver and X driver, or VT switching).
Moreover, X has grown to incorporate modern features like offscreen
rendering and scene composition, but subject to the limitations of the
X architecture. For example, the X implementation of composition adds
additional context switches and makes things like input redirection
difficult.
X architecture diagram
The diagram above illustrates the central role of the X server and
compositor in operations, and the steps required to get contents on to
the screen.
Over time, X developers came to understand the shortcomings of this
approach and worked to split things up. Over the past several years,
a lot of functionality has moved out of the X server and into
client-side libraries or kernel drivers. One of the first components
to move out was font rendering, with freetype and fontconfig providing
an alternative to the core X fonts. Direct rendering OpenGL as a
graphics driver in a client side library went through some iterations,
ending up as DRI2, which abstracted most of the direct rendering
buffer management from client code. Then cairo came along and provided
a modern 2D rendering library independent of X, and compositing
managers took over control of the rendering of the desktop as toolkits
like GTK+ and Qt moved away from using X APIs for rendering. Recently,
memory and display management have moved to the Linux kernel, further
reducing the scope of X and its driver stack. The end result is a
highly modular graphics stack.
The compositing manager as the display server
Wayland is a new display server and compositing protocol, and Weston
is the implementation of this protocol which builds on top of all the
components above. We are trying to distill out the functionality in
the X server that is still used by the modern Linux desktop. This
turns out to be not a whole lot. Applications can allocate their own
off-screen buffers and render their window contents directly, using
hardware accelerated libraries like libGL, or high quality software
implementations like those found in Cairo. In the end, what’s needed
is a way to present the resulting window surface for display, and a
way to receive and arbitrate input among multiple clients. This is
what Wayland provides, by piecing together the components already in
the eco-system in a slightly different way.
X will always be relevant, in the same way Fortran compilers and VRML
browsers are, but it’s time that we think about moving it out of the
critical path and provide it as an optional component for legacy
applications.
Overall, the philosophy of Wayland is to provide clients with a way to
manage windows and how their contents is displayed. Rendering is left
to clients, and system wide memory management interfaces are used to
pass buffer handles between clients and the compositing manager.
Wayland architecture diagram
The figure above illustrates how Wayland clients interact with a
Wayland server. Note that window management and composition are
handled entirely in the server, significantly reducing complexity
while marginally improving performance through reduced context
switching. The resulting system is easier to build and extend than a
similar X system, because often changes need only be made in one
place. Or in the case of protocol extensions, two (rather than 3 or 4
in the X case where window management and/or composition handling may
also need to be updated).
wayland-1.16.0/doc/publican/sources/Preface.xml 0000664 0000000 0000000 00000000765 12663124406 016256 0 ustar
%BOOK_ENTITIES;
]>
Acknowledgments
TODO: Kristian has to fill up this with one or two paragraphs and a small
"thank you": http://en.wikipedia.org/wiki/Preface
Best,
Kristian Høgsberg
wayland-1.16.0/doc/publican/sources/Protocol.xml 0000664 0000000 0000000 00000053646 13344007532 016515 0 ustar
%BOOK_ENTITIES;
]>
Wayland Protocol and Model of OperationBasic Principles
The Wayland protocol is an asynchronous object oriented protocol. All
requests are method invocations on some object. The requests include
an object ID that uniquely identifies an object on the server. Each
object implements an interface and the requests include an opcode that
identifies which method in the interface to invoke.
The protocol is message-based. A message sent by a client to the server
is called request. A message from the server to a client is called event.
A message has a number of arguments, each of which has a certain type (see
for a list of argument types).
Additionally, the protocol can specify enums which associate
names to specific numeric enumeration values. These are primarily just
descriptive in nature: at the wire format level enums are just integers.
But they also serve a secondary purpose to enhance type safety or
otherwise add context for use in language bindings or other such code.
This latter usage is only supported so long as code written before these
attributes were introduced still works after; in other words, adding an
enum should not break API, otherwise it puts backwards compatibility at
risk.
enums can be defined as just a set of integers, or as
bitfields. This is specified via the bitfield boolean
attribute in the enum definition. If this attribute is true,
the enum is intended to be accessed primarily using bitwise operations,
for example when arbitrarily many choices of the enum can be ORed
together; if it is false, or the attribute is omitted, then the enum
arguments are a just a sequence of numerical values.
The enum attribute can be used on either uint
or int arguments, however if the enum is
defined as a bitfield, it can only be used on
uint args.
The server sends back events to the client, each event is emitted from
an object. Events can be error conditions. The event includes the
object ID and the event opcode, from which the client can determine
the type of event. Events are generated both in response to requests
(in which case the request and the event constitutes a round trip) or
spontaneously when the server state changes.
State is broadcast on connect, events are sent
out when state changes. Clients must listen for
these changes and cache the state.
There is no need (or mechanism) to query server state.
The server will broadcast the presence of a number of global objects,
which in turn will broadcast their current state.
Code Generation
The interfaces, requests and events are defined in
protocol/wayland.xml.
This xml is used to generate the function prototypes that can be used by
clients and compositors.
The protocol entry points are generated as inline functions which just
wrap the wl_proxy_* functions. The inline functions aren't
part of the library ABI and language bindings should generate their
own stubs for the protocol entry points from the xml.
Wire Format
The protocol is sent over a UNIX domain stream socket, where the endpoint
usually is named wayland-0
(although it can be changed via WAYLAND_DISPLAY
in the environment). Beginning in Wayland 1.15, implementations can
optionally support server socket endpoints located at arbitrary
locations in the filesystem by setting WAYLAND_DISPLAY
to the absolute path at which the server endpoint listens.
Every message is structured as 32-bit words; values are represented in the
host's byte-order. The message header has 2 words in it:
The first word is the sender's object ID (32-bit).
The second has 2 parts of 16-bit. The upper 16-bits are the message
size in bytes, starting at the header (i.e. it has a minimum value of 8).The lower is the request/event opcode.
The payload describes the request/event arguments. Every argument is always
aligned to 32-bits. Where padding is required, the value of padding bytes is
undefined. There is no prefix that describes the type, but it is
inferred implicitly from the xml specification.
The representation of argument types are as follows:
intuint
The value is the 32-bit value of the signed/unsigned
int.
fixed
Signed 24.8 decimal numbers. It is a signed decimal type which
offers a sign bit, 23 bits of integer precision and 8 bits of
decimal precision. This is exposed as an opaque struct with
conversion helpers to and from double and int on the C API side.
string
Starts with an unsigned 32-bit length, followed by the
string contents, including terminating null byte, then padding
to a 32-bit boundary.
object
32-bit object ID.
new_id
The 32-bit object ID. On requests, the client
decides the ID. The only events with new_id are
advertisements of globals, and the server will use IDs below
0x10000.
array
Starts with 32-bit array size in bytes, followed by the array
contents verbatim, and finally padding to a 32-bit boundary.
fd
The file descriptor is not stored in the message buffer, but in
the ancillary data of the UNIX domain socket message (msg_control).
Versioning
Every interface is versioned and every protocol object implements a
particular version of its interface. For global objects, the maximum
version supported by the server is advertised with the global and the
actual version of the created protocol object is determined by the
version argument passed to wl_registry.bind(). For objects that are
not globals, their version is inferred from the object that created
them.
In order to keep things sane, this has a few implications for
interface versions:
The object creation hierarchy must be a tree. Otherwise,
infering object versions from the parent object becomes a much
more difficult to properly track.
When the version of an interface increases, so does the version
of its parent (recursively until you get to a global interface)
A global interface's version number acts like a counter for all
of its child interfaces. Whenever a child interface gets
modified, the global parent's interface version number also
increases (see above). The child interface then takes on the
same version number as the new version of its parent global
interface.
To illustrate the above, consider the wl_compositor interface. It
has two children, wl_surface and wl_region. As of wayland version
1.2, wl_surface and wl_compositor are both at version 3. If
something is added to the wl_region interface, both wl_region and
wl_compositor will get bumpped to version 4. If, afterwards,
wl_surface is changed, both wl_compositor and wl_surface will be at
version 5. In this way the global interface version is used as a
sort of "counter" for all of its child interfaces. This makes it
very simple to know the version of the child given the version of its
parent. The child is at the highest possible interface version that
is less than or equal to its parent's version.
It is worth noting a particular exception to the above versioning
scheme. The wl_display (and, by extension, wl_registry) interface
cannot change because it is the core protocol object and its version
is never advertised nor is there a mechanism to request a different
version.
Connect Time
There is no fixed connection setup information, the server emits
multiple events at connect time, to indicate the presence and
properties of global objects: outputs, compositor, input devices.
Security and Authentication
mostly about access to underlying buffers, need new drm auth
mechanism (the grant-to ioctl idea), need to check the cmd stream?
getting the server socket depends on the compositor type, could
be a system wide name, through fd passing on the session dbus.
or the client is forked by the compositor and the fd is
already opened.
Creating Objects
Each object has a unique ID. The IDs are allocated by the entity
creating the object (either client or server). IDs allocated by the
client are in the range [1, 0xfeffffff] while IDs allocated by the
server are in the range [0xff000000, 0xffffffff]. The 0 ID is
reserved to represent a null or non-existant object.
For efficiency purposes, the IDs are densely packed in the sense that
the ID N will not be used until N-1 has been used. Any ID allocation
algorithm that does not maintain this property is incompatible with
the implementation in libwayland.
Compositor
The compositor is a global object, advertised at connect time.
See for the
protocol description.
Surfaces
A surface manages a rectangular grid of pixels that clients create
for displaying their content to the screen. Clients don't know
the global position of their surfaces, and cannot access other
clients' surfaces.
Once the client has finished writing pixels, it 'commits' the
buffer; this permits the compositor to access the buffer and read
the pixels. When the compositor is finished, it releases the
buffer back to the client.
See for the protocol
description.
Input
A seat represents a group of input devices including mice,
keyboards and touchscreens. It has a keyboard and pointer
focus. Seats are global objects. Pointer events are delivered
in surface-local coordinates.
The compositor maintains an implicit grab when a button is
pressed, to ensure that the corresponding button release
event gets delivered to the same surface. But there is no way
for clients to take an explicit grab. Instead, surfaces can
be mapped as 'popup', which combines transient window semantics
with a pointer grab.
To avoid race conditions, input events that are likely to
trigger further requests (such as button presses, key events,
pointer motions) carry serial numbers, and requests such as
wl_surface.set_popup require that the serial number of the
triggering event is specified. The server maintains a
monotonically increasing counter for these serial numbers.
Input events also carry timestamps with millisecond granularity.
Their base is undefined, so they can't be compared against
system time (as obtained with clock_gettime or gettimeofday).
They can be compared with each other though, and for instance
be used to identify sequences of button presses as double
or triple clicks.
See for the
protocol description.
Talk about:
keyboard map, change events
xkb on Wayland
multi pointer Wayland
A surface can change the pointer image when the surface is the pointer
focus of the input device. Wayland doesn't automatically change the
pointer image when a pointer enters a surface, but expects the
application to set the cursor it wants in response to the pointer
focus and motion events. The rationale is that a client has to manage
changing pointer images for UI elements within the surface in response
to motion events anyway, so we'll make that the only mechanism for
setting or changing the pointer image. If the server receives a request
to set the pointer image after the surface loses pointer focus, the
request is ignored. To the client this will look like it successfully
set the pointer image.
The compositor will revert the pointer image back to a default image
when no surface has the pointer focus for that device. Clients can
revert the pointer image back to the default image by setting a NULL
image.
What if the pointer moves from one window which has set a special
pointer image to a surface that doesn't set an image in response to
the motion event? The new surface will be stuck with the special
pointer image. We can't just revert the pointer image on leaving a
surface, since if we immediately enter a surface that sets a different
image, the image will flicker. Broken app, I suppose.
Output
An output is a global object, advertised at connect time or as it
comes and goes.
See for the protocol
description.
laid out in a big (compositor) coordinate system
basically xrandr over Wayland
geometry needs position in compositor coordinate system
events to advertise available modes, requests to move and change
modes
Data sharing between clients
The Wayland protocol provides clients a mechanism for sharing
data that allows the implementation of copy-paste and
drag-and-drop. The client providing the data creates a
wl_data_source object and the clients
obtaining the data will see it as wl_data_offer
object. This interface allows the clients to agree on a mutually
supported mime type and transfer the data via a file descriptor
that is passed through the protocol.
The next section explains the negotiation between data source and
data offer objects.
explains how these objects are created and passed to different
clients using the wl_data_device interface
that implements copy-paste and drag-and-drop support.
See ,
,
and
for
protocol descriptions.
MIME is defined in RFC's 2045-2049. A
registry of MIME types is maintained by the Internet Assigned
Numbers Authority (IANA).
Data negotiation
A client providing data to other clients will create a wl_data_source
object and advertise the mime types for the formats it supports for
that data through the wl_data_source.offer
request. On the receiving end, the data offer object will generate one
wl_data_offer.offer event for each supported mime
type.
The actual data transfer happens when the receiving client sends a
wl_data_offer.receive request. This request takes
a mime type and a file descriptor as arguments. This request will generate a
wl_data_source.send event on the sending client
with the same arguments, and the latter client is expected to write its
data to the given file descriptor using the chosen mime type.
Data devices
Data devices glue data sources and offers together. A data device is
associated with a wl_seat and is obtained by the clients using the
wl_data_device_manager factory object, which is also responsible for
creating data sources.
Clients are informed of new data offers through the
wl_data_device.data_offer event. After this
event is generated the data offer will advertise the available mime
types. New data offers are introduced prior to their use for
copy-paste or drag-and-drop.
Selection
Each data device has a selection data source. Clients create a data
source object using the device manager and may set it as the
current selection for a given data device. Whenever the current
selection changes, the client with keyboard focus receives a
wl_data_device.selection event. This event is
also generated on a client immediately before it receives keyboard
focus.
The data offer is introduced with
wl_data_device.data_offer event before the
selection event.
Drag and Drop
A drag-and-drop operation is started using the
wl_data_device.start_drag request. This
requests causes a pointer grab that will generate enter, motion and
leave events on the data device. A data source is supplied as
argument to start_drag, and data offers associated with it are
supplied to clients surfaces under the pointer in the
wl_data_device.enter event. The data offer
is introduced to the client prior to the enter event with the
wl_data_device.data_offer event.
Clients are expected to provide feedback to the data sending client
by calling the wl_data_offer.accept request with
a mime type it accepts. If none of the advertised mime types is
supported by the receiving client, it should supply NULL to the
accept request. The accept request causes the sending client to
receive a wl_data_source.target event with the
chosen mime type.
When the drag ends, the receiving client receives a
wl_data_device.drop event at which it is expected
to transfer the data using the
wl_data_offer.receive request.
wayland-1.16.0/doc/publican/sources/Revision_History.xml 0000664 0000000 0000000 00000000251 12663124406 020216 0 ustar 1-0krhInitial version
wayland-1.16.0/doc/publican/sources/Server.xml 0000664 0000000 0000000 00000004262 12663124406 016153 0 ustar
%BOOK_ENTITIES;
]>
Server APIIntroduction
The open-source reference implementation of Wayland protocol is
split in two C libraries, libwayland-client and
libwayland-server. Their main responsibility is to handle the
Inter-process communication (IPC) with each
other, therefore guaranteeing the protocol objects marshaling and
messages synchronization.
The server library is designed to work much like libwayland-client,
although it is considerably complicated due to the server needing
to support multiple versions of the protocol. It is best to learn
libwayland-client first.
Each open socket to a client is represented by a wl_client. The equvalent
of the wl_proxy that
libwayland-client uses to represent an object is wl_resource for
client-created objects, and wl_global for objects
created by the server.
Often a server is also a client for another Wayland server, and
thus must link with both libwayland-client and libwayland-server.
This produces some type name conflicts (such as the client wl_display and
server wl_display,
but the duplicate-but-not-the-same types are opaque, and accessed
only inside the correct library where it came from. Naturally that
means that the program writer needs to always know if a pointer to
a wl_display is for the server or client side and use the
corresponding functions.
&doxygen;
wayland-1.16.0/doc/publican/sources/Wayland.ent 0000664 0000000 0000000 00000000214 12663124406 016263 0 ustar
wayland-1.16.0/doc/publican/sources/Wayland.xml 0000664 0000000 0000000 00000002150 13344007452 016274 0 ustar
%BOOK_ENTITIES;
]>
wayland-1.16.0/doc/publican/sources/Xwayland.xml 0000664 0000000 0000000 00000020624 13344007452 016472 0 ustar
%BOOK_ENTITIES;
]>
X11 Application SupportIntroduction
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.
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 of a
real X11 server.
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.
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.
Two Modes for Foreign Windows
In general, windows from a foreign window system can be presented in one
of two ways: rootless and rootful (not rootless).
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 advantage of this approach in Xwayland's
case is that you can run your favourite X11 window manager to manage your
X11 applications. The disadvantage is that the foreign windows do not
integrate with the native desktop. Therefore this mode is not usually
used.
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 advantage is that one can
freely stack and mix native and foreign windows, which is not possible in
rootful mode. The disadvantage is that this mode is harder to implement
and fundamental differences in window systems may prevent some things
from working. 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.
This chapter concentrates on the rootless mode, and ignores the rootful
mode.
Architecture
A Wayland compositor usually takes care of launching Xwayland.
Xwayland works in cooperation with a Wayland compositor as follows:
Xwayland architecture diagram
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.
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.
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.
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.
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. On the other hand, 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.
X Window Manager (XWM)
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.
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.
Window identification
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.
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.
wayland-1.16.0/doc/publican/sources/css/ 0000775 0000000 0000000 00000000000 12663124406 014747 5 ustar wayland-1.16.0/doc/publican/sources/css/brand.css 0000664 0000000 0000000 00000000426 12663124406 016551 0 ustar /*headings*/
h1, h2, h3, h4, h5, h6,
div.producttitle,
div.subtitle,
div.author div.author,
div.translator div.translator,
div.othercredit div.othercredit,
div.editor div.editor,
div.contrib div.contrib,
.title,
.titlepage .edition,
.titlepage .releaseinfo {
color: #336699;
}
wayland-1.16.0/doc/publican/sources/css/common.css 0000664 0000000 0000000 00000061066 12663124406 016762 0 ustar * {
widows: 4 !important;
orphans: 4 !important;
}
body, h1, h2, h3, h4, h5, h6, pre, li, div {
line-height: 1.29em;
}
body {
background-color: white;
margin:0 auto;
font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif;
font-size: 14px;
max-width: 770px;
color: black;
}
body.toc_embeded {
/*for web hosting system only*/
margin-left: 300px;
}
object.toc, iframe.toc {
/*for web hosting system only*/
border-style: none;
position: fixed;
width: 290px;
height: 99.99%;
top: 0;
left: 0;
z-index: 100;
border-style: none;
border-right:1px solid #999;
}
/* Hide web menu */
body.notoc {
margin-left: 3em;
}
iframe.notoc {
border-style:none;
border: none;
padding: 0px;
position:fixed;
width: 21px;
height: 29px;
top: 0px;
left:0;
overflow: hidden;
margin: 0px;
margin-left: -3px;
}
/* End hide web menu */
/* desktop styles */
body.desktop {
margin-left: 26em;
}
body.desktop .book > .toc {
display:block;
width:24em;
height:99.99%;
position:fixed;
overflow:auto;
top:0px;
left:0px;
/* padding-left:1em; */
background-color:#EEEEEE;
font-size: 12px;
}
body.pdf {
max-width: 100%;
}
.toc {
line-height:1.35em;
}
.toc .glossary,
.toc .chapter, .toc .appendix {
margin-top:1em;
}
.toc .part {
margin-top:1em;
display:block;
}
span.glossary,
span.appendix {
display:block;
margin-top:0.5em;
}
div {
padding-top:0px;
}
div.section {
page-break-inside: avoid;
}
p, div.para {
padding-top: 0px;
margin-top: 1em;
padding-bottom: 0px;
margin-bottom: 1em;
}
div.formalpara {
padding-top: 0px;
margin-top: 1em;
padding-bottom: 0px;
margin-bottom: 1em;
}
.varlistentry div.para {
page-break-before: avoid;
}
/*Links*/
a {
outline: none;
}
a:link {
text-decoration: none;
border-bottom: 1px dotted ;
color:#3366cc;
}
body.pdf a:link {
word-wrap: break-word;
}
a:visited {
text-decoration:none;
border-bottom: 1px dotted ;
color:#003366;
}
div.longdesc-link {
float:right;
color:#999;
}
.toc a, .qandaset a {
font-weight:normal;
border:none;
}
.toc a:hover, .qandaset a:hover
{
border-bottom: 1px dotted;
}
/*headings*/
h1, h2, h3, h4, h5, h6 {
color: #336699;
margin-top: 0px;
margin-bottom: 0px;
background-color: transparent;
margin-bottom: 0px;
margin-top: 20px;
page-break-inside: avoid;
page-break-after: avoid;
word-wrap: break-word;
}
h1 {
font-size: 22px;
}
.titlepage h1.title {
text-align:left;
}
.book > .titlepage h1.title {
text-align: center;
}
.article > .titlepage h1.title,
.article > .titlepage h2.title {
text-align: center;
}
.set .titlepage > div > div > h1.title {
text-align: center;
}
.part > .titlepage h1.title {
text-align: center;
font-size: 24px;
}
div.producttitle {
margin-top: 0px;
margin-bottom: 20px;
font-size: 48px;
font-weight: bold;
/* background: #003d6e url(../images/h1-bg.png) top left repeat-x; */
color: #336699;
text-align: center;
padding-top: 12px;
}
.titlepage .corpauthor {
margin-top: 1em;
text-align: center;
}
.section h1.title {
font-size: 18px;
padding: 0px;
color: #336699;
text-align: left;
background: white;
}
h2 {
font-size: 20px;
margin-top: 30px;
}
.book div.subtitle, .book h2.subtitle, .book h3.subtitle {
margin-top: 1em;
margin-bottom: 1em;
font-size: 18px;
text-align: center;
}
div.subtitle {
color: #336699;
font-weight: bold;
}
h1.legalnotice {
font-size: 24px;
}
.preface > div > div > div > h2.title,
.preface > div > div > div > h1.title {
margin-top: 1em;
font-size: 24px;
}
.appendix h2 {
font-size: 24px;
}
h3 {
font-size: 14px;
padding-top:0px;
padding-bottom: 0px;
margin-bottom: 0px;
}
h4 {
font-size: 14px;
padding-top:0px;
padding-bottom:0px;
}
h5 {
font-size: 14px;
}
h6 {
font-size: 14px;
margin-bottom: 0px;
}
.abstract h6 {
margin-top:1em;
margin-bottom:.5em;
font-size: 24px;
}
.index > div > div > div > h2.title {
font-size: 24px;
}
.chapter > div > div > div > h2.title {
font-size: 24px;
}
.section > div > div > div > h2.title {
font-size: 21px;
page-break-inside: avoid;
page-break-before: avoid;
page-break-after: avoid;
}
.section > div > div > div > h3.title {
font-size: 17px;
}
/*element rules*/
hr {
border-collapse: collapse;
border-style:none;
border-top: 1px dotted #ccc;
width:100%;
}
/* web site rules */
ul.languages, .languages li {
display:inline;
padding:0px;
}
.languages li a {
padding:0px .5em;
text-decoration: none;
}
.languages li p, .languages li div.para {
display:inline;
}
.languages li a:link, .languages li a:visited {
color:#444;
}
.languages li a:hover, .languages li a:focus, .languages li a:active {
color:black;
}
ul.languages {
display:block;
background-color:#eee;
padding:.5em;
}
/*supporting stylesheets*/
/*unique to the webpage only*/
.books {
position:relative;
}
.versions li {
width:100%;
clear:both;
display:block;
}
a.version {
font-size: 20px;
text-decoration:none;
width:100%;
display:block;
padding:1em 0px .2em 0px;
clear:both;
}
a.version:before {
content:"Version";
font-size: smaller;
}
a.version:visited, a.version:link {
color:#666;
}
a.version:focus, a.version:hover {
color:black;
}
.books {
display:block;
position:relative;
clear:both;
width:100%;
}
.books li {
display:block;
width:200px;
float:left;
position:relative;
clear: none ;
}
.books .html {
width:170px;
display:block;
}
.books .pdf {
position:absolute;
left:170px;
top:0px;
font-size: smaller;
}
.books .pdf:link, .books .pdf:visited {
color:#555;
}
.books .pdf:hover, .books .pdf:focus {
color:#000;
}
.books li a {
text-decoration:none;
}
.books li a:hover {
color:black;
}
/*products*/
.products li {
display: block;
width:300px;
float:left;
}
.products li a {
width:300px;
padding:.5em 0px;
}
.products ul {
clear:both;
}
/*revision history*/
.revhistory {
display:block;
}
.revhistory table {
background-color:transparent;
border-color:#fff;
padding:0px;
margin: 0;
border-collapse:collapse;
border-style:none;
}
.revhistory td {
text-align :left;
padding:0px;
border: none;
border-top: 1px solid #fff;
font-weight: bold;
}
.revhistory .simplelist td {
font-weight: normal;
}
.revhistory .simplelist {
margin-bottom: 1.5em;
margin-left: 1em;
}
.revhistory table th {
display: none;
}
/*credits*/
.authorgroup div {
clear:both;
text-align: center;
}
div.author div.author,
div.translator div.translator,
div.othercredit div.othercredit,
div.editor div.editor,
div.contrib div.contrib {
margin: 0px;
padding: 0px;
margin-top: 12px;
font-size: 14px;
font-weight: bold;
color: #336699;
}
div.editedby {
margin-top: 15px;
margin-bottom: -0.8em;
}
div.authorgroup .author,
div.authorgroup.editor,
div.authorgroup.translator,
div.authorgroup.othercredit,
div.authorgroup.contrib {
display: block;
font-size: 14px;
page-break-inside: avoid;
}
.revhistory .author {
display: inline;
}
.othercredit h3 {
padding-top: 1em;
}
.othercredit {
margin:0px;
padding:0px;
}
.releaseinfo {
clear: both;
}
.copyright {
margin-top: 1em;
}
/* qanda sets */
.answer {
margin-bottom:1em;
border-bottom:1px dotted #ccc;
}
.qandaset .toc {
border-bottom:1px dotted #ccc;
}
.question {
font-weight:bold;
}
.answer .data, .question .data {
padding-left: 2.6em;
}
.answer .label, .question .label {
float:left;
font-weight:bold;
}
/* inline syntax highlighting */
.perl_Alert {
color: #0000ff;
}
.perl_BaseN {
color: #007f00;
}
.perl_BString {
color: #5C3566;
}
.perl_Char {
color: #ff00ff;
}
.perl_Comment {
color: #888888;
}
.perl_DataType {
color: #0000ff;
}
.perl_DecVal {
color: #00007f;
}
.perl_Error {
color: #ff0000;
}
.perl_Float {
color: #00007f;
}
.perl_Function {
color: #007f00;
}
.perl_IString {
color: #5C3566;
}
.perl_Keyword {
color: #002F5D;
}
.perl_Operator {
color: #ffa500;
}
.perl_Others {
color: #b03060;
}
.perl_RegionMarker {
color: #96b9ff;
}
.perl_Reserved {
color: #9b30ff;
}
.perl_String {
color: #5C3566;
}
.perl_Variable {
color: #0000ff;
}
.perl_Warning {
color: #0000ff;
}
/*Lists*/
ul {
list-style-image: url("../images/dot.png");
list-style-type: circle;
padding-left: 1.6em;
}
ul ul {
list-style-image: url("../images/dot2.png");
list-style-type: circle;
}
ol.1 {
list-style-type: decimal;
}
ol.a,
ol ol {
list-style-type: lower-alpha;
}
ol.i {
list-style-type: lower-roman;
}
ol.A {
list-style-type: upper-alpha;
}
ol.I {
list-style-type: upper-roman;
}
dt {
font-weight:bold;
margin-bottom:0px;
padding-bottom:0px;
}
dd {
margin:0px;
margin-left:2em;
padding-top:0px;
}
li {
padding-top: 0px;
margin-top: 0px;
padding-bottom: 0px;
/* margin-bottom: 16px; */
}
/*images*/
img {
display:block;
margin: 2em 0;
max-width: 100%;
}
.inlinemediaobject,
.inlinemediaobject img,
.inlinemediaobject object {
display:inline;
margin:0px;
overflow: hidden;
}
.figure {
margin-top: 1em;
width: 100%;
}
.figure img,
.mediaobject img {
display:block;
margin: 0em;
page-break-inside: avoid;
}
.figure .title {
margin-bottom:2em;
padding:0px;
}
/*document modes*/
.confidential {
background-color:#900;
color:White;
padding:.5em .5em;
text-transform:uppercase;
text-align:center;
}
.longdesc-link {
display:none;
}
.longdesc {
display:none;
}
.prompt {
padding:0px .3em;
}
/*user interface styles*/
.screen .replaceable {
}
.guibutton, .guilabel {
font-family: "liberation mono", "bitstream vera mono", "dejavu mono", monospace;
font-weight: bold;
}
.example {
background-color: #ffffff;
border-left: 3px solid #aaaaaa;
padding-top: 1px;
padding-bottom: 0.1em;
padding-left: 1em;
}
.equation {
border-left: 3px solid #aaaaaa;
background-color: #ffffff;
padding-top: 1px;
padding-bottom: 0.1em;
padding-left: 1em;
}
.equation-contents {
margin-left: 4em;
}
div.title {
margin-bottom: 1em;
font-weight: 14px;
font-weight: bold;
color: #336699;
page-break-inside: avoid;
page-break-after: avoid;
word-wrap: break-word;
}
.example-contents {
background-color: #ffffff;
}
.example-contents .para {
/* padding: 10px;*/
}
/*terminal/console text*/
.computeroutput,
.option {
font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
font-weight:bold;
}
.replaceable {
font-style: italic;
}
.command, .filename, .keycap, .classname, .literal {
font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
font-weight:bold;
}
/* no bold in toc */
.toc * {
font-weight: inherit;
}
.toc H1 {
font-weight: bold;
}
div.programlisting {
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+ */
}
pre {
font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
display:block;
background-color: #f5f5f5;
color: #000000;
/* border: 1px solid #aaaaaa; */
margin-bottom: 1em;
padding:.5em 1em;
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+ */
font-size: 0.9em;
border-style:none;
box-shadow: 0 2px 5px #AAAAAA inset;
-moz-box-shadow: 0 2px 5px #AAAAAA inset;
-webkit-box-shadow: 0 2px 5px #AAAAAA inset;
-o-box-shadow: 0 2px 5px #AAAAAA inset;
}
body.pdf pre {
border: 1px solid #AAAAAA;
box-shadow: none;
-moz-box-shadow: none;
-webkit-box-shadow: none;
-o-box-shadow: none;
}
pre .replaceable,
pre .keycap {
}
code {
font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
white-space: pre-wrap;
word-wrap: break-word;
font-weight:bold;
}
.parameter code {
display: inline;
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+ */
}
code.email {
font-weight: normal;
font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif;
}
/*Notifications*/
div.warning:before {
content:url(../images/warning.png);
padding-left: 5px;
}
div.note:before {
content:url(../images/note.png);
padding-left: 5px;
}
div.important:before {
content:url(../images/important.png);
padding-left: 5px;
}
div.warning, div.note, div.important {
color: black;
margin: 0px;
padding: 0px;
background: none;
background-color: white;
margin-bottom: 1em;
border-bottom: 1px solid #aaaaaa;
page-break-inside: avoid;
}
div.admonition_header p {
margin: 0px;
padding: 0px;
color: #eeeeec;
padding-top: 0px;
padding-bottom: 0px;
height: 1.4em;
line-height: 1.4em;
font-size: 17px;
display:inline;
}
div.admonition_header {
background-origin:content-box;
clear: both;
margin: 0px;
padding: 0px;
margin-top: -40px;
padding-left: 58px;
line-height: 1.0px;
font-size: 1.0px;
}
div.warning div.admonition_header {
background: url(../images/red.png) top left repeat-x;
background-color: #590000;
background: -webkit-linear-gradient(#a40000,#590000);
background: linear-gradient(#a40000,#590000);
}
div.note div.admonition_header {
background: url(../images/green.png) top right repeat-x;
background-color: #597800;
background: -webkit-linear-gradient(#769f00,#597800);
background: linear-gradient(#769f00,#597800);
}
div.important div.admonition_header {
background: url(../images/yellow.png) top right repeat-x;
background-color: #a6710f;
background: -webkit-linear-gradient(#d08e13,#a6710f);
background: linear-gradient(#d08e13,#a6710f);
}
div.warning p:first-child,
div.warning div.para:first-child,
div.note p:first-child,
div.note div.para:first-child,
div.important p:first-child,
div.important div.para:first-child {
padding: 0px;
margin: 0px;
}
div.admonition {
border: none;
border-left: 1px solid #aaaaaa;
border-right: 1px solid #aaaaaa;
padding:0px;
margin:0px;
padding-top: 1.5em;
padding-bottom: 1em;
padding-left: 2em;
padding-right: 1em;
background-color: #eeeeec;
-moz-border-radius: 0px;
-webkit-border-radius: 0px;
border-radius: 0px;
}
/*Page Title*/
#title {
display:block;
height:45px;
padding-bottom:1em;
margin:0px;
}
#title a.left{
display:inline;
border:none;
}
#title a.left img{
border:none;
float:left;
margin:0px;
margin-top:.7em;
}
#title a.right {
padding-bottom:1em;
}
#title a.right img {
border:none;
float:right;
margin:0px;
margin-top:.7em;
}
/*Table*/
div.table {
/* page-break-inside: avoid; */
}
table {
border: 1px solid #444;
width:100%;
border-collapse:collapse;
table-layout: fixed;
word-wrap: break-word;
}
table.blockquote,
table.simplelist,
.calloutlist table {
border-style: none;
}
table th {
text-align:left;
background-color:#6699cc;
padding:.3em .5em;
color:white;
}
table td {
padding:.15em .5em;
}
table tr.even td {
background-color:#f5f5f5;
}
tr:nth-child(even) {
background-color: #eeeeee;
}
table th p:first-child, table td p:first-child, table li p:first-child,
table th div.para:first-child, table td div.para:first-child, table li div.para:first-child {
margin-top:0px;
padding-top:0px;
display:inline;
}
th, td {
border-style:none;
vertical-align: top;
/* border: 1px solid #000; */
}
.blockquote td,
.simplelist th,
.simplelist td {
border: none;
}
table table td {
border-bottom:1px dotted #aaa;
background-color:white;
padding:.6em 0px;
}
table table {
border:1px solid white;
}
td.remarkval {
color:#444;
}
td.fieldval {
font-weight:bold;
}
.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost {
color:white;
font-weight:bold;
background-color:#999;
width:120px;
}
td.remarkval {
width:230px;
}
td.tname {
font-weight:bold;
}
th.dbfield {
width:120px;
}
th.dbtype {
width:70px;
}
th.dbdefault {
width:70px;
}
th.dbnul {
width:70px;
}
th.dbkey {
width:70px;
}
span.book {
margin-top:4em;
display:block;
font-size: 11pt;
}
span.book a{
font-weight:bold;
}
span.chapter {
display:block;
}
table.simplelist td, .calloutlist table td {
border-style: none;
}
table.lt-4-cols.lt-7-rows td {
border: none;
}
/*to simplify layout*/
table.lt-4-cols.gt-14-rows tr:nth-child(odd) {
background-color: #fafafa;
}
/* to keep simple but stripe rows */
.gt-8-cols td {
border-left: 1px solid #ccc;
}
.gt-8-cols td:first-child {
border-left: 0;
}
/* to apply vertical lines to differentiate columns*/
/*Breadcrumbs*/
#breadcrumbs ul li.first:before {
content:" ";
}
#breadcrumbs {
color:#900;
padding:3px;
margin-bottom:25px;
}
#breadcrumbs ul {
margin-left:0;
padding-left:0;
display:inline;
border:none;
}
#breadcrumbs ul li {
margin-left:0;
padding-left:2px;
border:none;
list-style:none;
display:inline;
}
#breadcrumbs ul li:before {
content:"\0020 \0020 \0020 \00BB \0020";
color:#333;
}
dl {
margin-top: 0px;
margin-left: 28px;
}
.toc dl {
margin-left: 10px;
}
/*index*/
.glossary h3,
.index h3 {
font-size: 20px;
color:#aaa;
margin:0px;
}
.indexdiv {
margin-bottom:1em;
}
.glossary dt,
.index dt {
color:#444;
padding-top:.5em;
}
.glossary dl dl dt,
.index dl dl dt {
color:#777;
font-weight:normal;
padding-top:0px;
}
.index dl dl dt:before {
content:"- ";
color:#ccc;
}
/*changes*/
.footnote {
font-size: 10px;
margin: 0px;
color: #222;
}
.footnotes {
margin-bottom: 60px;
}
table .footnote {
}
sup {
margin:0px;
padding:0px;
font-size: 10px;
padding-left:0px;
}
.footnote {
position:relative;
}
.footnote sup {
color: black;
left: .4em;
}
.footnote a:link,
.footnote a:visited {
text-decoration:none;
border: none;
}
.footnote .para sup {
/* position:absolute; */
vertical-align:text-bottom;
}
a.footnote {
padding-right: 0.5em;
text-decoration:none;
border: none;
}
.footnote sup a:link,
.footnote sup a:visited {
color:#92917d;
text-decoration:none;
}
.footnote:hover sup a {
text-decoration:none;
}
.footnote p,.footnote div.para {
padding-left:1em;
}
.footnote a:link,
.footnote a:visited before{
color:#00537c;
}
.footnote a:hover {
}
/**/
.pdf-break {
page-break-before: always;
}
div.legalnotice {
page-break-before: always;
}
div.abstract {
page-break-before: always;
/* page-break-after: always;*/
}
div.chapter {
page-break-before: always;
}
div.titlepage, div.titlepage > div, div.titlepage > div > div {
page-break-inside: avoid;
page-break-after: avoid;
}
div.preface, div.part {
page-break-before: always;
}
div.appendix {
page-break-before: always;
}
div.section {
page-break-inside: auto;
page-break-before: auto;
page-break-after: auto;
}
dt.varlistentry {
page-break-inside: avoid;
page-break-after: avoid;
}
dd {
page-break-before: avoid;
}
div.note .replaceable,
div.important .replaceable,
div.warning .replaceable,
div.note .keycap,
div.important .keycap,
div.warning .keycap
{
}
ul li p:last-child, ul li para:last-child {
margin-bottom:0px;
padding-bottom:0px;
}
/*document navigation*/
.docnav a, .docnav strong {
border:none;
text-decoration:none;
font-weight:normal;
}
.docnav {
list-style:none;
margin:0px;
padding:0px;
position:relative;
width:100%;
padding-bottom:2em;
padding-top:1em;
height:2.5em;
line-height:2.5em;
/*
border-top:1px dotted #ccc;
background-color: rgba(240, 240, 240, 0.9);
-webkitbox-shadow: 0px .15em .5em rgba(0,0,0,0.2);
-moz-box-shadow: 0px .15em .5em rgba(0,0,0,0.2);
box-shadow: 0px .15em .5em rgba(0,0,0,0.2);
*/
}
.docnav li {
list-style:none;
margin:0px;
padding:0px;
display:inline;
font-size: 14px;
}
.docnav li:before {
content:" ";
}
.docnav li.previous, .docnav li.next {
position:absolute;
top:1.5em;
}
.docnav li.up, .docnav li.home {
margin:0px 1.5em;
}
.docnav.top li.home {
color: #336699;
font-size: 22pt;
font-weight: bold;
}
.docnav li.previous {
left:0px;
text-align:left;
}
.docnav li.next {
right:0px;
text-align:right;
}
.docnav li.previous strong, .docnav li.next strong {
height: 17px;
display: block;
}
.docnav {
margin:0 auto;
text-align:center;
}
.docnav li.next a strong {
background: url(../images/stock-go-forward.png) right 120% no-repeat;
padding-top:3px;
padding-bottom:4px;
padding-right:28px;
}
.docnav li.previous a strong {
background: url(../images/stock-go-back.png) left 120% no-repeat;
padding-top:3px;
padding-bottom:4px;
padding-left:28px;
padding-right:0.5em;
}
.docnav li.home a strong {
background: url(../images/stock-home.png) top left no-repeat;
padding:5px;
padding-left:28px;
}
.docnav li.up a strong {
background: url(../images/stock-go-up.png) top left no-repeat;
padding:5px;
padding-left:28px;
}
.docnav a:link, .docnav a:visited {
color:#666;
}
.docnav a:hover, .docnav a:focus, .docnav a:active {
color:black;
}
.docnav a {
max-width: 10px;
overflow:hidden;
}
.docnav a:link strong {
text-decoration:none;
}
.docnav {
margin:0 auto;
text-align:center;
}
ul.docnav {
margin-bottom: 1em;
}
/* Reports */
.reports ul {
list-style:none;
margin:0px;
padding:0px;
}
.reports li{
margin:0px;
padding:0px;
}
.reports li.odd {
background-color: #eeeeee;
margin:0px;
padding:0px;
}
.reports dl {
display:inline;
margin:0px;
padding:0px;
float:right;
margin-right: 17em;
margin-top:-1.3em;
}
.reports dt {
display:inline;
margin:0px;
padding:0px;
}
.reports dd {
display:inline;
margin:0px;
padding:0px;
padding-right:.5em;
}
.reports h2, .reports h3{
display:inline;
padding-right:.5em;
font-size: 14px;
font-weight:normal;
}
.reports div.progress {
display:inline;
float:right;
width:16em;
background:#c00 url(../images/shine.png) top left repeat-x;
margin:0px;
margin-top:-1.3em;
padding:0px;
border:none;
}
/*uniform*/
body.results, body.reports {
max-width:57em ;
padding:0px;
}
/*Progress Bar*/
div.progress {
display:block;
float:left;
width:16em;
background:#c00 url(../images/shine.png) top left repeat-x;
height:1em;
}
div.progress span {
height:1em;
float:left;
}
div.progress span.translated {
background:#6c3 url(../images/shine.png) top left repeat-x;
}
div.progress span.fuzzy {
background:#ff9f00 url(../images/shine.png) top left repeat-x;
}
/*Results*/
.results ul {
list-style:none;
margin:0px;
padding:0px;
}
.results li{
margin:0px;
padding:0px;
}
.results li.odd {
background-color: #eeeeee;
margin:0px;
padding:0px;
}
.results dl {
display:inline;
margin:0px;
padding:0px;
float:right;
margin-right: 17em;
margin-top:-1.3em;
}
.results dt {
display:inline;
margin:0px;
padding:0px;
}
.results dd {
display:inline;
margin:0px;
padding:0px;
padding-right:.5em;
}
.results h2, .results h3 {
display:inline;
padding-right:.5em;
font-size: 14px;
font-weight:normal;
}
.results div.progress {
display:inline;
float:right;
width:16em;
background:#c00 url(../images/shine.png) top left repeat-x;
margin:0px;
margin-top:-1.3em;
padding:0px;
border:none;
}
/* Dirty EVIL Mozilla hack for round corners */
pre {
-moz-border-radius:11px;
-webkit-border-radius:11px;
border-radius: 11px;
/* page-break-inside: avoid; */
}
.example {
-moz-border-radius:0px;
-webkit-border-radius:0px;
border-radius: 0px;
page-break-inside: avoid;
}
/* move these invisible fields out of the flow */
.example > a:first-child,
.table > a:first-child {
float: left;
}
.package, .citetitle {
font-style: italic;
}
.titlepage .edition,
.titlepage .releaseinfo {
color: #336699;
background-color: transparent;
margin-top: 1em;
margin-bottom: 1em;
font-size: 20px;
font-weight: bold;
text-align: center;
}
span.remark {
background-color: #ff00ff;
}
.draft {
background-image: url(../images/watermark-draft.png);
background-repeat: repeat-y;
background-position: center;
}
.foreignphrase {
font-style: inherit;
}
dt {
clear:both;
page-break-inside: avoid;
page-break-after: avoid;
}
dt img {
border-style: none;
max-width: 112px;
}
dt object {
max-width: 112px;
}
dt .inlinemediaobject, dt object {
display: inline;
float: left;
margin-bottom: 1em;
padding-right: 1em;
width: 112px;
}
dl:after {
display: block;
clear: both;
content: "";
}
.toc dd {
padding-bottom: 0px;
margin-bottom: 1em;
padding-left: 1.3em;
margin-left: 0px;
}
div.toc > dl > dt {
padding-bottom: 0px;
margin-bottom: 0px;
margin-top: 1em;
}
.strikethrough {
text-decoration: line-through;
}
.underline {
text-decoration: underline;
}
.calloutlist img, .callout {
padding: 0px;
margin: 0px;
width: 12pt;
display: inline;
vertical-align: middle;
}
li.step > a:first-child {
display: block;
}
.stepalternatives {
list-style-image: none;
list-style-type: upper-alpha;
}
.task {
/* page-break-inside: avoid; */
}
.added {
background-color: #99ff99;
}
.changed {
background-color: #ffff77;
}
.deleted {
background-color: #ff4455;
text-decoration: line-through;
}
wayland-1.16.0/doc/publican/sources/css/default.css 0000664 0000000 0000000 00000000122 12663124406 017100 0 ustar @import url("common.css");
@import url("overrides.css");
@import url("lang.css");
wayland-1.16.0/doc/publican/sources/css/epub.css 0000664 0000000 0000000 00000002110 12663124406 016406 0 ustar /*headings*/
h1, h2, h3, h4, h5, h6,
div.producttitle,
div.subtitle,
div.author div.author,
div.translator div.translator,
div.othercredit div.othercredit,
div.editor div.editor,
div.contrib div.contrib,
.title,
.titlepage .edition {
}
div.para {
margin-top: 1em;
}
/* inline syntax highlighting */
.perl_Alert {
color: #0000ff;
}
.perl_BaseN {
color: #007f00;
}
.perl_BString {
color: #5C3566;
}
.perl_Char {
color: #ff00ff;
}
.perl_Comment {
color: #888888;
}
.perl_DataType {
color: #0000ff;
}
.perl_DecVal {
color: #00007f;
}
.perl_Error {
color: #ff0000;
}
.perl_Float {
color: #00007f;
}
.perl_Function {
color: #007f00;
}
.perl_IString {
color: #5C3566;
}
.perl_Keyword {
color: #002F5D;
}
.perl_Operator {
color: #ffa500;
}
.perl_Others {
color: #b03060;
}
.perl_RegionMarker {
color: #96b9ff;
}
.perl_Reserved {
color: #9b30ff;
}
.perl_String {
color: #5C3566;
}
.perl_Variable {
color: #0000ff;
}
.perl_Warning {
color: #0000ff;
}
b, strong {
font-weight: bolder;
}
code.command {
font-family: monospace;
font-weight: bolder;
}
wayland-1.16.0/doc/publican/sources/css/print.css 0000664 0000000 0000000 00000000277 12663124406 016623 0 ustar @import url("common.css");
@import url("overrides.css");
@import url("lang.css");
#tocframe {
display: none;
}
body.toc_embeded {
margin-left: 30px;
}
.producttitle {
color: #336699;
}
wayland-1.16.0/doc/publican/sources/images/ 0000775 0000000 0000000 00000000000 13344007452 015422 5 ustar wayland-1.16.0/doc/publican/sources/images/icon.svg 0000664 0000000 0000000 00000005124 12663124406 017077 0 ustar
wayland-1.16.0/doc/publican/sources/images/wayland.png 0000664 0000000 0000000 00000013021 12663124406 017566 0 ustar PNG
IHDR u ǐ sBIT|d pHYs Z Z`yc tEXtSoftware www.inkscape.org< IDATxyŝ?=33p &J⭸j1#јUlݨYb(^I!""r00}sQGUw