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>
Dispmanx elements are like hardware overlays. Assign one weston_surface
to each overlay created, and the VideoCore will composite it on screen.
The maximum number of elements is configurable via the command line.
Specifying zero will disable the overlays (planes/elements) altogether,
and use only GLESv2 compositing.
You need an up-to-date Raspberry Pi firmware for:
- vc_dispmanx_resource_create(), that will also take stride. Otherwise
surfaces ending up in elements may show up as corrupted.
- off-line compositing support. The on-line compositing of elements
cannot handle too many elements. Look for the comments around
DEFAULT_MAX_PLANES in the code.
Elements must be double-buffered to avoid tearing. Therefore two buffers
(Dispmanx resources) are allocated for each element. A command line
option is added to allow single-buffering instead to save memory, with
the risk of tearing.
The page flip timer is replaced with the Dispmanx update completion
callback. The callback is executed in a separate thread, therefore a
pipe is set up to integrate properly with Weston core.
If not disabled, usually all surfaces are assigned into planes, and
nothing is composited in GLESv2. Planes do not support surface
transformations though, so compositing will automatically switch the
necessary surfaces to GLESv2 compositing as needed. Switching between
GLESv2 and elements may cause transient visual glitches and jerks.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a new backend for the Raspberry Pi.
This backend uses the DispmanX API to initialise the display, and create
an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer".
No X server is involved. All compositing happens through GLESv2.
The created EGLSurface is specifically configured as buffer content
preserving, otherwise Weston wouuld show only the latest damage and
everything else was black. This may be sub-optimal, since we are not
alternating between two buffers, like the DRM backend is, and content
preserving may imply a fullscreen copy on each frame.
Page flips are not properly hooked up yet. The display update will
block, and we use a timer to call weston_output_finish_frame(), just
like the x11 backend does.
This backend handles the VT and tty just like the DRM backend does.
While VT switching works in theory, the display output seems to be
frozen while switched away from Weston. You can still switch back.
Seats and connectors cannot be explicitly specified, and multiple seats
are not expected.
Udev is used to find the input devices. Input devices are opened
directly, weston-launch is not supported at this time. You may need to
confirm that your pi user has access to input device nodes.
The Raspberry Pi backend is built by default. It can be build-tested
without the Raspberry Pi headers and libraries, because we provide stubs
in rpi-bcm-stubs.h, but such resulting binary is non-functional. If
using stubs, the backend is built but not installed.
VT and tty handling, and udev related code are pretty much copied from
the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is
copied from the headers on Raspberry Pi, including their copyright
notice, and modified.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Tomeu Vizoso
Pekka Paalanen