This has a couple of additional implications for the internal weston API:
1) weston_view_configure no longer exists. Use weston_view_set_position
instead.
2) The weston_surface.configure callback no longer takes a width and
height. If you need these, surface.width/height are set before
configure is called. If you need to know when the width/height
changes, you must track that yourself.
This is needed for XWayland surfaces with alpha channel, as X will be
sending crap in there that should be discarded.
This is currently done with a copy in the compositor, while we wait for
support in the VideoCore side.
The symbol is needed only for the EGL buffer path. If --disable-egl is
given to ./configure, there is no need for it, so fix it to actually not
look for that symbol needlessly.
This should fix the runtime error:
Failed to load module: .../rpi-backend.so: undefined symbol:
vc_dispmanx_set_wl_buffer_in_use
when you use --disable-egl and do not have a recent enough
libraspberrypi package (/opt/vc, a.k.a userland.git) that would provide
vc_dispmanx_set_wl_buffer_in_use. Apparently no released version of
userland yet provides this.
The calls are organized into two helper functions to avoid a boolean
argument, and put the #ifdefs away from the main parts of the code.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net>
This wraps all accesses to an SHM buffer between wl_shm_buffer_begin
and end so that wayland-shm can install a handler for SIGBUS and catch
attempts to pass the compositor a buffer that is too small.
Remove create_surface() and destroy_surface() from the renderer
interface and change the renderers to create surface state on demand
and destroy it using the weston_surface's destroy signal.
Also make sure the surfaces' renderer state is reset to NULL on
destruction.
This is a step towards runtime switchable renderers.
(rpi-renderer changes are only compile-tested)
The compositor will check if the client destroyed the wl_buffer
while it was in use in a display update, and delete the resource
itself once the update has finished.
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>
This commit adds a weston_buffer structure to replace wl_buffer. This way
we can hold onto buffers by just their resource. In order to do this, the
every renderer.attach function has to fill in the weston_buffer.width and
weston_buffer.height fields.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
Dispmanx is the prorietary display API on the Raspberry Pi, which
provides hardware compositing. Every visible surface is assigned a
Dispmanx element, and the hardware or firmware will do all compositing
onto screen. The API supports translation, scaling, flips, discrete
rotations in 90-degree steps, alpha channel on the surfaces, and
full-surface alpha on top.
Previously, Dispmanx capabilities were used via the weston_plane
mechanism, where surfaces were assigned to planes when possible, and
otherwise transparently falling back to GLESv2 compositing. Because we
have no way to use the same memory buffer as a GL texture and a Dispmanx
resource, we had to prepare for both. In the worst case, that means one GL
texture, and two (double-buffered case) Dispmanx resources, all the size
of a whole surface, for all surfaces. This was eating memory fast. To
make things worse (and less slow), the wl_shm buffer was kept around,
since it was copied to either a texture or a resource as needed. This
caused all clients to need two buffers. In a Dispmanx-only renderer, we
can drop the GL texture, and we can release wl_shm buffer immediately
after the first copy, so clients become effectively single-buffered. So
from the worst case of 5 buffers per surface, we go down to 3 or just
2 (single-buffered Dispmanx element, one wl_shm buffer in the client)
buffers per surface.
As this will replace the GL renderer on rpi, we cannot fall back to the
GLESv2 compositing anymore. We lose arbitrary surface rotation, but we
lose also the GL fallback, which caused glitches.
This patch depends on new RaspberryPi firmware. Older firmware may not
render ARGB surfaces correctly, solid color surfaces maybe cause a
performance hit, and the output may completely fail in case the firmware
does not fall back internal off-line compositing properly as needed.
This new rpi-renderer support surface translation and scaling, but not
rotation or transpose (not even in 90-deg steps). In theory, 90-deg step
surface rotation is possible to support. Output transformations are
supported, but flipped variants do not seem to work right.
As a detail, menus and other surfaces that are simply translated with
respect to another surface caused falling back to the GL renderer. The
rpi-renderer handles them directly.
This patch only adds the new renderer, but does not hook it up into use.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Jason Ekstrand
Tomeu Vizoso
Pekka Paalanen
Neil Roberts
Ander Conselvan de Oliveira
Hardening
Daniel Stone
Pekka Paalanen