rpi: Dispmanx elements as planes, completion callback
authorPekka Paalanen <ppaalanen@gmail.com>
Wed, 7 Nov 2012 10:25:15 +0000 (12:25 +0200)
committerKristian Høgsberg <krh@bitplanet.net>
Thu, 8 Nov 2012 21:56:26 +0000 (16:56 -0500)
commit7fb46fbe95c7480ee6e8e63858455fc32684bb00
tree632dcd912567554c99ceb48e94c29ceb2a825f83
parente8de35c922871bc5b15fbf0436efa233a6db8e41
rpi: Dispmanx elements as planes, completion callback

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>
src/compositor-rpi.c
src/rpi-bcm-stubs.h