weston

Jason Ekstrand a7af70436b Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is not a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>		11 years ago
clients	Rename invocations of frame_create that were missed by `ee7fefcf`	11 years ago
data	window.c: frame_button: Maximize, minimize, close, icon buttons in window frame	13 years ago
man	compositor-drm: Support configuring the framebuffer format from weston.ini	11 years ago
protocol	protocol: Add missing xml files to EXTRA_DIST	13 years ago
shared	Use cairo-util frame in tinytoolkit	11 years ago
src	Split the geometry information from weston_surface out into weston_view	11 years ago
tests	Split the geometry information from weston_surface out into weston_view	11 years ago
wcap	Add more missing config.h #includes	11 years ago
.gitignore	Update .gitignore	11 years ago
COPYING	Add COPYING	13 years ago
Makefile.am	autotools: Don't use wayland-scanner.m4	12 years ago
README	Flesh out README a bit, link to building instructions	13 years ago
autogen.sh	Update autotools configuration	14 years ago
configure.ac	launcher: add logind backend	11 years ago
notes.txt	Add informal notes file	12 years ago
wayland-scanner.mk	autotools: Don't use wayland-scanner.m4	12 years ago
weston.ini	compositor-drm: Support configuring the framebuffer format from weston.ini	11 years ago

README

Weston

Weston is the reference implementation of a Wayland compositor, and a
useful compositor in its own right.  Weston has various backends that
lets it run on Linux kernel modesetting and evdev input as well as
under X11.  Weston ships with a few example clients, from simple
clients that demonstrate certain aspects of the protocol to more
complete clients and a simplistic toolkit.  There is also a quite
capable terminal emulator (weston-terminal) and an toy/example desktop
shell.  Finally, weston also provides integration with the Xorg server
and can pull X clients into the Wayland desktop and act as a X window
manager.

Refer to http://wayland.freedesktop.org/building.html for buiding
weston and its dependencies.