1 Commits (a30989a47d0b4dc1365f0c34cb9ec71584024041)

Author	SHA1	Message	Date
Pekka Paalanen	d7265bc4ac	rpi: add a Dispmanx renderer ... 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>	12 years ago