weston

Ander Conselvan de Oliveira 555c17ddd8 compositor-drm: refactor to avoid unnecessary allocation of KMS FBs Currently, the drm backend will create and destroy a KMS FB for each frame. However, the bos for a gbm surface are reused (at least with mesa) so we can store the fb_id on it and destroy it only on the bo's destroy callback. To use the same path for scanning out client buffers, some refactor was needed. Previously, the bo for the client buffer was destroyed early so that gbm_surface_release_buffer() would not be called with it, since at the page flip handler output->scanout_buffer can be NULL even if the current frame is a client buffer. This was solved by adding a drm_fb structure that holds a gbm_bo, an fb_id, and information about the fb coming from a client buffer or not. A drm_fb is created in such a way that it is destroyed whenever the bo it references is destroyed. The fields current_* and next_* in drm_output are changed into only two pointers to drm_fb's.		14 years ago
clients	window: Set window title and class	14 years ago
data	…
protocol	screenshooter: Grab pixel data directly before buffer swap	14 years ago
shared	…
src	compositor-drm: refactor to avoid unnecessary allocation of KMS FBs	14 years ago
tests	tests: Add event-test, which tests for a few incoming events	14 years ago
.gitignore	…
COPYING	Add COPYING	14 years ago
Makefile.am	…
README	…
autogen.sh	…
configure.ac	…
weston.ini	shell-animation: add conf option in shell	14 years ago

README

Wayland Demos

This repository contains a few demos application for the Wayland
project.  There's a sample compositor that can run on KMS, under X11
or under another Wayland compositor and there's a handful of simple
clients that demonstrate various aspects of Wayland: