他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)Blender is the free and open source 3D creation suite. It supports the entirety of the 3D pipeline—modeling, rigging, animation, simulation, rendering, compositing and motion tracking, even video editing and game creation.
Get Involved
Blender is a public project, made by hundreds of people f by studios and individual artists, professionals and hobbyists, scientists, students, VFX experts, animators, game artists, modders, and the list goes on.
Cycles Render EngineCycles is Blender’s built-in powerful unbiased path-tracer engine that offers stunning ultra-realistic rendering.
Real-time viewport preview
CPU & GPU rendering
PBR shaders & HDR lighting support
VR rendering support
Modeling, Sculpt, UVBlender’s comprehensive array of modeling tools make creating, transforming and editing your models a breeze.
Full N-Gon support
Edge slide, inset, grid and bridge fill, and more
Advanced sculpting tools and brushes
Multi-resolution and Dynamic subdivision
3D painting with textured brushes and masking
Python scripting for custom tools and add-ons
VFXVFX professionals say: “Probably the best tracker in the market”. Blender includes production ready camera and object tracking. Allowing you to import raw footage, track the footage, mask areas and see the camera movements live in your 3d scene. Eliminating the need to switch between programs.
Auto and Manual tracking
Powerful camera reconstruction
Real-time preview of your tracked footage and 3D scene
Support for Planar tracking and Tripod solvers
Animation & RiggingThanks to the high quality rigging and animation tools, Blender is being used for numerous short films, advertisements, TV series and feature films now.
Envelope, skeleton and automatic skinning
B-spline interpolated bones
Curve editor and dope sheets
Custom bone shapes for fast input
Sound synchronization
Story Art, drawing 2d in 3dReally! Drawing directly in a 3D viewport makes a lot of sense. It opens unsurpassed workflow freedom for story-boarders and 2D artists.
Combine 2D with 3D right in the viewport
Full Animation Support with Onion Skinning
Layers & Colors for Stroke and Fill
Sculpt brush strokes & Parent to 3D objects
Make it your ownBlender has a flexible Python controlled interface. Layout, colors, size and even fonts can be adjusted. Use hundreds of add-ons by the community or create your own using Blender’s accessible Python API.
Customize the interface layout and colors
Hi-res/Retina screen support
Create your own tools and add-ons
Draw over the OpenGL viewport
Connect with Blender’s Render API
background: Manuel Grad - manuelgrad.at
Follow Blender
Artistic freedom starts with Blender
The Free and Open Source 3D Creation SuiteFrom Wikipedia, the free encyclopedia
Wayland is a computer
that specifies the communication between a
(called a Wayland compositor[]) and its clients, as well as a reference implementation of the protocol in the .
Wayland is developed by a group of volunteers initially led by Kristian H?gsberg as a
community-driven project with the aim of replacing the
with a modern, simpler
operating systems. The project's source code is published under the terms of the , a .
As part of its efforts, the Wayland project also develops a reference implementation of a Wayland compositor called .
module of the
gets an event and sends it to the .
The Wayland compositor looks through its
to determine which window should receive the event. The scenegraph corresponds to what is on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph. Thus, the Wayland 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 by the client via , and the client just sends a request to the compositor to indicate the region that was updated.
The Wayland compositor collects damage requests from its clients and then re-composites the screen. The compositor can then directly issue an
to schedule a pageflip with .
In recent years,[] Linux desktop graphics has moved from having "a pile of
interfaces... all talking to the , which is at the center of the universe" towards putting the Linux kernel and its components (i.e. , ) "in the middle", with "window systems like X and Wayland ... off in the corner". This will be "a much-simplified graphics system offering more flexibility and better performance".
Kristian H?gsberg could have added an
as many recent projects have done, but preferred to "[push] X out of the hotpath between clients and the hardware" for reasons explained in the project's FAQ:
What’s different now is that a lot of infrastructure has moved from the
into the kernel (memory management, command scheduling, ) or libraries (, pixman, , , , etc.), and there is very little left that has to happen in a central server process. ... [An X server has] a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. ... This includes code tables, glyph rasterization and caching,
(seriously, XLFDs!), and the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extension such as ,
... With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if [we] don’t plan for it.
Wayland consists of a protocol and a reference implementation named . The project is also developing versions of
that render to Wayland instead of to X. Most applications are expected to gain support for Wayland through one of these libraries without modification to the application.
Initial versions of Wayland have not provided , though H?gsberg noted in 2010 that network transparency is possible. It was attempted as a
project in 2011, but was not successful. Adam Jackson has envisioned providing remote access to a Wayland application by either "pixel-scraping" (like ) or getting it to send a "rendering command stream" across the network (as in ,
or ). As of early 2013, H?gsberg is experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor. In August 2017, GNOME saw the first such pixel-scraping VNC server implementation under Wayland.
In the Wayland protocol architecture, a client and a compositor communicate through the Wayland protocol using the reference implementation libraries.
Wayland protocol follows a
in which clients are the graphical applications requesting the display of pixel buffers on the screen, and the server (compositor) is the service provider controlling the display of these buffers.
The Wayland reference implementation has been designed as a two-layer protocol:
A low-level layer or wire protocol that handles the
between the two involved ?—?client and compositor?—?and the
of the data that they interchange. This layer is message-based and usually implemented using the kernel IPC services, specifically
in the case of
operating systems.:9
A high-level layer built upon it, that handles the information that client and compositor need to exchange to implement the basic features of a . This layer is implemented as "an asynchronous object-oriented protocol".:9
While the low-level layer was written manually in , the high-level layer is automatically generated from a description of the elements of the protocol stored in
format. Every time the protocol description of this XML file changes, the C source code that implements such protocol can be regenerated to include the new changes, allowing a very flexible, extensible and error-proof protocol.
The reference implementation of Wayland protocol is split in two : a library to be used by Wayland clients called libwayland-client and a library to be used by Wayland compositors called libwayland-server.:57
The Wayland protocol is described as an "asynchronous
protocol".:9 Object-oriented means that the services offered by the compositor are presented as a series of objects living on the same compositor. Each object implements an interface which has a name, a number of methods (called requests) as well as several associated events. Every request and event has zero or more arguments, each one with a name and a . The protocol is asynchronous in the sense that requests do not have to wait for synchronized replies or , avoiding
and achieving improved performance.
The Wayland clients can make a request (a method invocation) on some object if the object's interface supports that request. The client must also supply the required data for the arguments of such request. This is the way the clients request services from the compositor. The compositor in turn sends information back to the client by causing the object to emit events (probably with arguments too). These events can be emitted by the compositor as a response to a certain request, or asynchronously, subject to the occurrence of internal events (such as one from an input device) or state changes. The error conditions are also signaled as events by the compositor.:9
For a client to be able to make a request to an object, it first needs to tell the server the ID number it will use to identify that object.:9 There are two types of objects in the compositor: global objects and non-global objects. Global objects are advertised by the compositor to the clients when they are created (and also when they are destroyed), while non-global objects are usually created by other objects that already exist as part of their functionality.
The interfaces and their requests and events are the core elements that define the Wayland protocol. Each version of the protocol includes a set of interfaces, along with their requests and events, which are expected to be in any Wayland compositor. Optionally, a Wayland compositor may define and implement its own interfaces that support new requests and events, thereby extending functionality beyond the core protocol.:10 To facilitate changes to the protocol, each interface contains a "version number" attribute in
this attribute allows for distinguishing variants of the same interface. Each Wayland compositor exposes not only what interfaces are available, but also the supported versions of those interfaces.:12
The interfaces of the current version of Wayland protocol are defined in the file protocol/wayland.xml of the Wayland source code. This is an
file that lists the existing interfaces in the current version, along with their requests, events and other attributes. This set of interfaces is the minimum required to be implemented by any Wayland compositor.
Some of the most basic interfaces of the Wayland protocol are::10-12
wl_display –
the core global object, a special object to encapsulate the Wayland protocol itself
wl_registry –
the global registry object, in which the compositor registers all the global objects that it wants to be available to all clients
wl_compositor –
an object that represents the compositor, and is in charge of combining the different surfaces into one output
wl_surface –
an object representing a rectangular area on the screen, defined by a location, size and pixel content
wl_buffer –
an object that, when attached to a wl_surface object, provides its displayable content
wl_output –
an object representing the displayable area of a screen
wl_pointer, wl_keyboard, wl_touch –
objects representing different input devices like
wl_seat –
an object representing a seat (a set of input/output devices) in
A typical Wayland client session starts by opening a connection to the compositor using the wl_display object. This is a special local object that represents the connection and does not live within the server. By using its interface the client can request the wl_registry global object from the compositor, where all the global object names live, and bind those that the client is interested in. Usually the client binds at least a wl_compositor object from where it will request one or more wl_surface objects to show the application output on the display.
A Wayland compositor can define and export its own additional interfaces.:10 This feature is used to extend the protocol beyond the basic functionality provided by the core interfaces, and has become the standard way to implement Wayland protocol extensions. Certain compositors can choose to add custom interfaces to provide specialized or unique features. The Wayland reference compositor, Weston, used them to implement new experimental interfaces as a testbed for new concepts and ideas, some of which later became part of the core protocol (such as wl_subsurface interface added in Wayland 1.4).
XDG-Shell protocol (see
for XDG) is an extended way to manage surfaces under Wayland compositors (not only Weston). The traditional way to manipulate (maximize, minimize, fullscreen, etc.) surfaces is to use the wl_shell_*() functions, which are part of the core Wayland protocol and live in libwayland-client. An implementation of the xdg-shell protocol, on the contrary, is supposed to be provided by the Wayland compositor. So you will find the xdg-shell-client-protocol.h header in the Weston source tree. Each Wayland compositor is supposed to provide its own implementation.
As of June 2014, XDG-Shell protocol was not versioned and still prone to changes.
xdg_shell is a protocol aimed to substitute wl_shell in the long term, but will not be part of the Wayland core protocol. It starts as a non-stable API, aimed to be used as a development place at first, and once features are defined as required by several desktop shells, it can be finally made stable. It provides mainly two new interfaces: xdg_surface and xdg_popup. The xdg_surface interface implements a desktop-style window that can be moved, resized, maximized, etc.; it provides a request for creating child/parent relationship. The xdg_popup interface implements a desktop-style popup/ an xdg_popup is always transient for another surface, and also has implicit grab.
IVI-Shell is an extension to the Wayland core protocol, targeting
(IVI) devices.
and its clients use
The Wayland protocol does not include a rendering API.:7:2 Instead, Wayland follows a direct rendering model, in which the client must render the window contents to a buffer shareable with the compositor.:7 For that purpose, the client can choose to do all the rendering by itself, use a rendering library like
or , or rely on the rendering engine of high-level widget libraries with Wayland support, such as
or . The client can also optionally use other specialized libraries to perform specific tasks, such as
The resulting buffer with the rendered window contents are stored in a wl_buffer object. The internal type of this object is implementation dependent. The only requirement is that the content data must be shareable between the client and the compositor. If the client uses a software (CPU) renderer and the result is stored in the , then client and compositor can use
to implement the buffer communication without extra copies. The Wayland protocol already provides natively this kind of shared memory buffers through wl_shm and wl_shm_pool interfaces .:11, 20-21 The drawback of this method is that the compositor may need to do additional work (usually to copy the shared data to the GPU) to display it, which leads to slower graphics performance.
The most typical case is for the client to render directly into a
buffer using a hardware (GPU) accelerated API such as ,
or . Client and compositor can share this GPU-space buffer using a special handler to reference it. This method allows the compositor to avoid additional copies of data to the GPU, resulting in faster graphics performance than using shm buffers, and therefore the preferred one. The compositor can further optimize the composition of the final scene to show on the display by using the same hardware acceleration API as the client.
When the rendering is done and the buffer shared, the Wayland client should instruct the compositor to present the rendered contents of the buffer on the display. For this purpose, the client binds the buffer object that stores the rendered contents to the surface object, and sends a "commit" request to the surface, transferring the effective control of the buffer to the compositor. Then, the client waits for the compositor to release the buffer (signaled by an event) if it wants to reuse the buffer to render another frame, or it can use another buffer to render the new frame and, when the rendering is finished, to bind this new buffer to the surface and commit its contents.:7 The procedure used for rendering, including the number of buffers involved and their management, is entirely under the client control.:7
There are several differences between Wayland and X in regards to performance, code maintainability, and security:
Architecture 
is a separate, additional feature in X, while Wayland merges display server and compositor as a single function. Also, it incorporates some of the tasks of the , which in X is a separate client-side process.
Compositing 
Compositing is optional in X, but mandatory in Wayland. Compositing in X is "active"; that is, the compositor must fetch all pixel data, which introduces latency. In Wayland, compositing is "passive", which means the compositor receives pixel data directly from clients.:8-11
Rendering 
The X server itself is able to perform rendering, although it can also be instructed to display a rendered window sent by a client. In contrast, Wayland does not expose any API for rendering, but delegates to clients such tasks (including the rendering of fonts, widgets, etc.). Window decorations can be rendered on the client side (e.g., by a graphics toolkit) or on the server side (by the compositor).
Security 
Wayland isolates the input and output of every window, achieving confidentiality, integrity and availa the original X design lacks these important security features, although some extensions have been developed trying to mitigate it. Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security.
Inter-process communication 
The X server provides a basic communication method between X clients, later extended by
conventions. This X client-to-client communication is used by window managers and also to implement , , and other features. Wayland core protocol does not support communication between wayland clients at all, and the corresponding functionality (if needed) should be implemented by the
(like KDE or GNOME), or by a third party (for example, by using native
of the underlying operating system).
Networking 
The X Window System is an
that was designed at its core to run over a network. Wayland does not offer network tr however, a compositor can implement any
to achieve remote displaying. In addition, there is research into Wayland image streaming and compression that would provide remote frame buffer access similar to that of .
A screenshot showing xwayland
running as a Wayland client, thus capable of displaying native X11 client applications in a Wayland compositor environment. This is similar to the way
runs X applications in ’s native windowing system. The goal of XWayland is to facilitate the transition from X Window System to Wayland environments, providing a way to run unported applications in the meantime. XWayland was mainlined into
version 1.16.
Widget toolkits such as
can switch their graphical back-end at run time, allowing users to choose at
whether they want to run the application over X or over Wayland. Qt 5 provides the -platform command-line option to that effect, whereas GTK+ 3 lets users select the desired
back-end by setting the GDK_BACKEND .
Typical elements of a . Neither Wayland nor X11 specifies what software is responsible for rendering the . Weston requires that they are drawn by the client, but
will implement server-side decoration.
that implement the Wayland display server protocol are also called Wayland compositors because they additionally perform the task of a .
of a W Weston implements client-side decoration
Lipstick –
framework which implements Wayland compositor. It is used in ,
has full Wayland support since version 0.20.
had incomplete Wayland support in April 2013.
maintains a separate branch for the integration of Wayland for GNOME 3.9 (in September 2013).
is a simple example Wayland compositor using Clutter.
is a Wayland compositor library that allows applications to create their own Wayland displays, which allows nesting and embedding of third party applications.
Weston running on
Weston is the reference implementation of a Wayland compositor also developed by the Wayland project. It is written in
and published under the . Weston only has official support for the
operating system due to its dependence on certain features of the , such as ,
(GEM), and , which have not been implemented in other Unix-like operating systems. When running on Linux, handling of the input hardware relies on , while the handling of buffers relies on
(GBM). However, in 2013 a prototype port of Weston to
was announced.
Weston relies on GEM to share application buffers between the compositor and applications. It contains a plugin system of "shells" for common desktop features like docks and panels. Clients are responsible for the drawing of their window borders and their decorations. For rendering, Weston can use
or the pixman library to do . The full OpenGL implementation is not used, because on most current systems, installing the full OpenGL libraries would also install
support libraries as dependencies.
Maynard is a
and has been written as a plugin for Weston, just as the
has been written as a plugin to .
A remote access interface for Weston was proposed in October 2013 by a
libinput was created to consolidate the input stack across multiple Wayland compositors.
Libinput handles input devices for multiple Wayland compositors and also provides a generic
input driver. It aims to provide one implementation for multiple Wayland compositors with a common way to handle input events while minimizing the amount of custom input code compositors need to include. libinput provides device detection[] (via ), device handling, input device event processing and abstraction.
Version 1.0 of libinput followed version 0.21, and included support for tablets, button sets and touchpad gestures. This version will maintain stable API/ABI.
As GNOME/GTK+ and
have mainlined the required changes, Fedora 22 will replace X.Org's evdev and Synaptics drivers with libinput.
The Weston code for handling input devices (keyboards, pointers, touch screens, etc.) was split into its own separate library, called libinput, for which support was first merged in Weston 1.5.
With version 1.16, the
obtained support for the
library in form of a wrapper called xf86-input-libinput.
Wayland Security Module is a proposition that resembles the
interface found in the .
Some applications (especially the ones related to ) require privileged capabilities that should work across different Wayland compositors. Currently,[] applications under Wayland are generally unable to perform any sensitive tasks such as taking screenshots or injecting input events. Wayland developers are actively looking for feasible ways to handle privileged clients securely and then designing privileged interfaces for them.
Wayland Security Module is a way to delegate security decisions within the compositor to a centralized security decision engine.
As explained in the "Software architecture" section above, the Wayland protocol is designed to be simple so that additional protocols and interfaces need to be defined and implemented to achieve a holistic windowing system. As of July 2014, these additional interfaces are actively being worked on. So, while the toolkits already fully support Wayland, the developers of the
are cooperating with the Wayland developers creating the necessary additional interfaces.
In general, out of the box support for a full desktop running Wayland in major Linux distributions is still in early stages. Most Linux distributions that ship version 3.20 or newer of the Gnome desktop environment do support manually installing a Wayland session, and in case of Gnome 3.22 or newer might default to Wayland. Notable early adopters that provide Wayland out of the box are:
starting with version 25 uses Wayland for the default GNOME 3.22 desktop session, with
as a fallback if the graphics driver cannot support Wayland.
RebeccaBlackOS is a
Debian-based Linux distribution that allows a convenient way to try out a real Wayland desktop without having to make any modifications to the main operating system of the computer. It is being used since as early as 2012 to showcase Wayland.
ships Wayland as default in Ubuntu 17.10 (Artful Aardvark) Ubuntu will revert back to X.Org for Ubuntu 18.04 LTS, as Wayland still has issues with screen sharing and remote desktop applications, and it recovers better from window manager crashes.
Toolkits supporting Wayland include the following:
has complete Wayland support.
has complete Wayland support, except for selection.
3.20 has complete Wayland support.
has complete Wayland support.
support for Wayland debuted with the 2.0.2 release and was enabled by default since version 2.0.4.
3.2 has Wayland support.
has initial Wayland support.
Desktop environments in process of being ported from X to Wayland include ,
is a desktop environment that exclusively supports Wayland.
In November 2015, Enlightenment e20 was announced with "full Wayland support". GNOME 3.20 was the first version "to have a full Wayland session". GNOME 3.22 now defaults to Wayland. GNOME 3.24 will ship the NVidia patches developed for Fedora 25.
Wayland support for KDE Plasma was delayed until the release of Plasma 5, though previously
4.11 got an experimental Wayland support. The version 5.4 of Plasma was the first with a Wayland session.
Other software supporting Wayland includes the following:
is working on Wayland support, it could be ready for Fedora 22.
published a Wayland developer preview in July 2014.
framework that runs under Wayland.
supports Wayland with wlterm.
has Wayland support integrated.
was made to run on Wayland during a -Project in 2014.
(Window System Interface) is a set of API calls serve a similar purpose as EGL does for OpenGL ES or GLX for OpenGL. Vulkan WSI includes support for Wayland from day one: VK_USE_PLATFORM_WAYLAND_KHR. Vulkan clients can run on unmodified Wayland servers, including Weston, GENIVI LayerManager, Mutter / GNOME Shell, Enlightenment, and more. The WSI allows applications to discover the different GPUs on the system, and display the results of GPU rendering to a window system.
Mobile and embedded hardware supporting Wayland includes the following:
: The GENIVI automotive industry consortium for
(IVI) supports Wayland.
in collaboration with
and work on improving performance and memory consumption, but do not expect to be able to replace X11 as the default display server until later in 2013.
: Smartphones from Jolla use Wayland. It is also used as standard when Linux
is used with hardware from other vendors or when it is installed into Android devices by users.
: Tizen up to 2.x supports Wayland in
(IVI) setups and from 3.0 onward defaults to Wayland.
Wayland uses
Kristian H?gsberg, a
graphics and
who previously worked on
and , started Wayland as a spare-time project in 2008 while working for . His stated goal was a system in which "every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker." H?gsberg was driving through the town of
when the underlying concepts "crystallized", hence the name.
In October 2010, Wayland became a
project. As part of the migration the prior
was replaced by the wayland-devel mailing list as the project's central point of discussion and development.
The Wayland client and server libraries were initially released under the , while the reference compositor Weston and some example clients used the . Later all the GPL code
under the MIT license "to make it easier to move code between the reference implementation and the actual libraries". In 2015 it was discovered that the license text used by Wayland was a slightly different and older version of the MIT license, and the license text was updated to the current version used by the
(known as ).
Wayland works with all
drivers with
support as well as
drivers via the .
The developers of Wayland are largely current
developers.
Major Wayland and Weston releases
Main features
Old version, no longer supported: 0.85
9 February 2012
First release
Old version, no longer supported: 0.95
24 July 2012
Began API stabilization
Old version, no longer supported: 1.0
22 October 2012
Stable wayland-client API
Old version, no longer supported: 1.1
15 April 2013
Software rendering. FBDEV, RDP backends
Old version, no longer supported: 1.2
12 July 2013
Stable wayland-server API
Color management. Subsurfaces.
Old version, no longer supported: 1.3
11 October 2013
More pixel formats. Support for language bindings
Old version, no longer supported: 1.4
23 January 2014
New wl_subcompositor and wl_subsurface interfaces
Multiple framebuffer formats. logind support for rootless Weston
Old version, no longer supported: 1.5
20 May 2014
libinput. Fullscreen shell.
Old version, no longer supported: 1.6
19 September 2014
libinput by default
Old version, no longer supported: 1.7
14 February 2015
Support for the Wayland presentation extension and for surface roles.
shell protocol.
Old version, no longer supported: 1.8
2 June 2015
Separated headers for core and generated protocol
Repaint scheduling. Named outputs. Output transformations. Surface-shooting API.
Old version, no longer supported: 1.9
21 September 2015
Updated license
Updated license. New test framework. Triple-head DRM compositor. linux_dmabuf extension.
Old version, no longer supported: 1.10
17 February 2016
Drag-and-drop functionality, grouped pointer events
Video 4 Linux 2, touch input, debugging improvements
Old version, no longer supported: 1.11
1 June 2016
New backup loading routine, new setup logic
Proxy wrappers, shared memory changes, Doxygen-generated HTML docs
Old version, no longer supported: 1.12
21 September 2016
Debugging support improved
libweston and libweston-desktop. Pointer locking and confinement. Relative pointer support.
Current stable version: 1.13
24 February 2017
The ABI of Weston has been changed, thus the new version was named 2.0.0 rather than 1.13.0
Old version
Older version, still supported
Latest version
Latest preview version
Future release
Harrington, Bryce (15 September 2015). .
(Mailing list).
. freedesktop.org 2015.
Larabel, Michael (10 June 2015). . Phoronix.com 2016.
. Wayland project 2016.
. Wayland project 2016.
Corbet, Jonathan (5 November 2010). . LWN.net 2016.
H?gsberg, Kristian (9 November 2010). . Wayland isn't a remote rendering API like X, but that doesn't exclude network transparency. Clients render into a shared buffer and then have to tell the compositor (...) what they changed. The compositor can then send the new pixels in that region out over the network. The Wayland protocol is already violently asynchronous, so it should be able to handle a bit of network lag gracefully. Remote fullscreen video viewing or gaming isn't going to work well, [but] I don't know any other display system that handles that well and transparently.
Larabel, Michael (18 August 2011). . Phoronix.com 2016.
Jackson, Adam (9 November 2010). .
Stone, Daniel (28 January 2013).
(Speech). linux.conf.au 2013. Canberra 2016.
Willis, Nathan (13 February 2013). . LWN.net 2016.
Daniel Aleksandersen. . Ctrl.blog 2017.
H?gsberg, Kristian.
(PDF) 2016.
H?gsberg, Kristian. . FreeDesktop.org 2014.
Paalanen, Pekka (25 July 2014).
H?gsberg, Kristian (24 January 2014). . wayland-devel mailing list.
. . 3 December .
Vervloesem, Koen (15 February 2012). . LWN.net 2016.
Barnes, Jesse.
(PDF). Intel Open Source Technology Center 2016. Does not include a rendering API – Clients use what they want and send buffer handles to the server
Paalanen, Pekka (21 November 2012).
2016. Buffer sharing works by creating a handle for a buffer, and passing that handle to another process which then uses the handle to make the GPU access again the same buffer.
Griffith, Eric (7 June 2013). . Phoronix.com. p. 2 2016.
. Wayland project 2016.
Edge, Jake (11 April 2012). . LWN.net 2016.
(PDF) 2016.
Graesslin, Martin (7 February 2013).
Kerrisk, Michael (25 September 2012). . LWN.net 2016.
Peres, Martin (21 February 2014).
Graesslin, Martin (23 November 2015).
. X.Org Foundation 2017. The X server has long included an extension, SECURITY, which provides support for a simple trusted/untrusted connection model.
Wiggins, David P. (15 November 1996). . X Consortium Standard 2017.
Walsh, Eamon F. (2009).
. Wayland project 2014.
. . 17 July 2014.
H?gsberg, Kristian (3 January 2011).
. Qt Wiki 2016.
. GNOME wiki 2016.
Edge, Jake (31 July 2013). . LWN.net 2016.
Larabel, Michael (30 November 2015). . Phoronix.com 2016.
Graesslin, Martin (21 April 2013).
Larabel, Michael (16 February 2013). . Phoronix.com 2016.
Paalanen, Pekka (10 March 2012).
Larabel, Michael (6 January 2013). . Phoronix.com 2016.
H?gsberg, Kristian (9 December 2010). .
. 16 April .
. . 18 October 2013.
. Freedesktop.org 2014.
Hutterer, Peter (8 October 2014).
(Speech). The X.Org Developer Conference 2014. Bordeaux 2016.
H?gsberg, Kristian (20 May 2014). . wayland-devel mailing list.
?dahl, Jonas (12 November 2013). . Wayland mailing list.
Hutterer, Peter (24 September 2014).
de Goede, Hans (1 February 2015).
(PDF) 2016.
Dodier-Lazaro, S Peres, Martin (9 October 2014).
(Speech). The X.Org Developer Conference 2014. Bordeaux 2016.
. Phoronix.
. Sourceforge.
. Phoronix.
. Phoronix.
. Canonical.
. Canonical.
Bassi, Emmanuele (31 January 2011). . clutter-announce (Mailing list).
Bradford, Rob (16 December 2011).
2016. The Clutter client side support is basically complete
Bassi, Emmanuele (24 September 2013). . clutter-announce (Mailing list).
. Archived from
on 29 March .
Lantinga, Sam (8 March 2014). . SDL Project 2014.
Larabel, Michael (9 January 2016). . Phoronix.com 2016.
Berglund, Camilla (8 April 2014).
. GNOME Wiki 2016.
. KDE Community Wiki 2016.
. Enlightenment.org 2016.
. Enlightenment.org 2016.
. FOSDEM.org 2016.
. GNOME Project 2015.
. Phoronix.
. Phoronix.
. 25 July 2014.
Larabel, Michael (14 June 2013). . Phoronix.com 2016.
Graesslin, Martin (29 June 2015).
Schaller, Christian (3 July 2014). . blogs.gnome.org 2016.
. 8 July 2014.
. . 9 July 2014.
. Posterous. 2 April 2013. Archived from
on 17 May .
. Murray's Blog. 2 April .
. Freedesktop.org 2014.
Hillesley, Richard (13 February 2012). . The H Open. Heise Media UK. p. .
. 18 August 2014.
Stone, Daniel (16 February 2016). .
. GENIVI Alliance 2013.[]
. Collabora 2013.
. Raspberry Pi 2013.
. LinuxG.net. 14 July .
VDVsx [@VDVsx] (13 July 2013).
(Tweet) – via .
Jolla [@JollaHQ] (13 July 2013).
(Tweet) – via .
. Tizen Wiki 2013.
VanCutsem, Geoffroy (10 July 2013). . IVI (Mailing list).
Amadeo, Ron. .
H?gsberg, Kristian (3 November 2008).
. FOSDEM Archive. 29 January .
Hillesley, Richard (13 February 2012). . The H Open. Heise Media UK 2016.
H?gsberg, Kristian. . Linux Plumbers Conference, 2009.
Jenkins, Evan (22 March 2011). . Ars Technica 2016.
Larabel, Michael (29 October 2010). . Phoronix.com 2016.
H?gsberg, Kristian (29 October 2010).
H?gsberg, Kristian (3 December 2008). . wayland-display-server (Mailing list).
H?gsberg, Kristian (22 November 2010). . wayland-devel (Mailing list).
H?gsberg, Kristian (19 September 2011). . wayland-devel (Mailing list).
Munk, Carsten (11 April 2013). . Mer Project 2013.
Munk, Carsten (8 June 2013). . Mer Project 2013.
Larabel, Michael (11 April 2013). . Phoronix.com 2016.
. Wayland.freedesktop.org 2013.
H?gsberg, Kristian (9 February 2012). . wayland-devel mailing list.
H?gsberg, Kristian (24 July 2012). . wayland-devel mailing list.
H?gsberg, Kristian (22 October 2012). . wayland-devel mailing list.
Scherschel, Fabian (23 October 2012). . The H Open. Heise Media UK 2016.
Larabel, Michael (16 April 2013). . Phoronix.com 2016.
H?gsberg, Kristian (15 April 2013). . wayland-devel mailing list.
Larabel, Michael (13 July 2013). . Phoronix.com 2016.
H?gsberg, Kristian (12 July 2013). . wayland-devel mailing list.
H?gsberg, Kristian (11 October 2013). . wayland-devel mailing list.
Paalanen, Pekka (19 September 2014). . wayland-devel mailing list.
Harrington, Bryce (14 February 2015). . wayland-devel mailing list.
Harrington, Bryce (14 February 2015). . wayland-devel mailing list.
Harrington, Bryce (2 June 2015). . wayland-devel mailing list.
Harrington, Bryce (2 June 2015). . wayland-devel mailing list.
Harrington, Bryce (21 September 2015). . wayland-devel (Mailing list).
Harrington, Bryce (21 September 2015). . wayland-devel (Mailing list).
Harrington, Bryce (17 February 2016). . wayland-devel (Mailing list).
Harrington, Bryce (17 February 2016). . wayland-devel (Mailing list).
Nestor, Marius (18 February 2016). . .
Larabel, Michael (16 February 2016). . Phoronix.com 2016.
Harrington, Bryce (1 June 2016). . wayland-devel (Mailing list) 2016.
Harrington, Bryce (1 June 2016). . wayland-devel (Mailing list) 2016.
Harrington, Bryce (21 September 2016). . wayland-devel (Mailing list) 2016.
Harrington, Bryce (21 September 2016). . wayland-devel (Mailing list) 2016.
Harrington, Bryce (21 February 2017). . wayland-devel (Mailing list) 2017.
Harrington, Bryce (25 February 2017). . wayland-devel (Mailing list) 2017.
Cite error: A
named "fedora wayland" is not used in the content (see the ).
H?gsberg, Kristian. .
Brockmeier, Joe 'Zonker' (17 November 2010). . .
Hillesley, Richard (13 February 2012). . .
Griffith, Eric (7 June 2013). . Phoronix.
projects hosted by
: Hidden categories:}