3 Commits (0af26c4fe7ab9d3d2bfe08566b5b15a677998b2c)

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>	13 years ago
Pekka Paalanen	7fb46fbe95	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>	13 years ago
Pekka Paalanen	e8de35c922	rpi: a backend for Raspberry Pi ... 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>	13 years ago