You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
weston/src/rpi-bcm-stubs.h

315 lines
7.8 KiB

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>
12 years ago
/*
Copyright (c) 2012, Broadcom Europe Ltd
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the copyright holder nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/*
* This file provides just enough types and stubs, so that the rpi-backend
* can be built without the real headers and libraries of the Raspberry Pi.
*
* This file CANNOT be used to build a working rpi-backend, it is intended
* only for build-testing, when the proper headers are not available.
*/
#ifndef RPI_BCM_STUBS
#define RPI_BCM_STUBS
#include <stdint.h>
/* from /opt/vc/include/bcm_host.h */
static inline void bcm_host_init(void) {}
static inline void bcm_host_deinit(void) {}
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
/* from /opt/vc/include/interface/vmcs_host/vc_dispservice_defs.h */
#define TRANSFORM_HFLIP (1<<0)
#define TRANSFORM_VFLIP (1<<1)
#define TRANSFORM_TRANSPOSE (1<<2)
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>
12 years ago
/* from /opt/vc/include/interface/vctypes/vc_display_types.h */
typedef enum
{
VCOS_DISPLAY_INPUT_FORMAT_INVALID = 0,
} DISPLAY_INPUT_FORMAT_T;
/* from /opt/vc/include/interface/vctypes/vc_image_types.h */
typedef struct tag_VC_RECT_T {
int32_t x;
int32_t y;
int32_t width;
int32_t height;
} VC_RECT_T;
typedef enum {
VC_IMAGE_ROT0,
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
/* these are not the right values: */
VC_IMAGE_ROT90,
VC_IMAGE_ROT180,
VC_IMAGE_ROT270,
VC_IMAGE_MIRROR_ROT0,
VC_IMAGE_MIRROR_ROT90,
VC_IMAGE_MIRROR_ROT180,
VC_IMAGE_MIRROR_ROT270,
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>
12 years ago
} VC_IMAGE_TRANSFORM_T;
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>
12 years ago
typedef enum
{
VC_IMAGE_MIN = 0,
/* these are not the right values: */
VC_IMAGE_ARGB8888,
VC_IMAGE_XRGB8888,
VC_IMAGE_RGB565,
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>
12 years ago
} VC_IMAGE_TYPE_T;
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>
12 years ago
/* from /opt/vc/include/interface/vmcs_host/vc_dispmanx_types.h */
typedef uint32_t DISPMANX_DISPLAY_HANDLE_T;
typedef uint32_t DISPMANX_UPDATE_HANDLE_T;
typedef uint32_t DISPMANX_ELEMENT_HANDLE_T;
typedef uint32_t DISPMANX_RESOURCE_HANDLE_T;
typedef uint32_t DISPMANX_PROTECTION_T;
#define DISPMANX_NO_HANDLE 0
#define DISPMANX_PROTECTION_NONE 0
#define DISPMANX_ID_HDMI 2
typedef enum {
/* Bottom 2 bits sets the alpha mode */
DISPMANX_FLAGS_ALPHA_FROM_SOURCE = 0,
DISPMANX_FLAGS_ALPHA_FIXED_ALL_PIXELS = 1,
DISPMANX_FLAGS_ALPHA_FIXED_NON_ZERO = 2,
DISPMANX_FLAGS_ALPHA_FIXED_EXCEED_0X07 = 3,
DISPMANX_FLAGS_ALPHA_PREMULT = 1 << 16,
DISPMANX_FLAGS_ALPHA_MIX = 1 << 17
} DISPMANX_FLAGS_ALPHA_T;
typedef struct {
DISPMANX_FLAGS_ALPHA_T flags;
uint32_t opacity;
DISPMANX_RESOURCE_HANDLE_T mask;
} VC_DISPMANX_ALPHA_T;
typedef struct {
int32_t width;
int32_t height;
VC_IMAGE_TRANSFORM_T transform;
DISPLAY_INPUT_FORMAT_T input_format;
} DISPMANX_MODEINFO_T;
typedef enum {
DISPMANX_NO_ROTATE = 0,
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
DISPMANX_ROTATE_90 = 1,
DISPMANX_ROTATE_180 = 2,
DISPMANX_ROTATE_270 = 3,
DISPMANX_FLIP_HRIZ = 1 << 16,
DISPMANX_FLIP_VERT = 1 << 17
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>
12 years ago
} DISPMANX_TRANSFORM_T;
typedef struct {
uint32_t dummy;
} DISPMANX_CLAMP_T;
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>
12 years ago
typedef void (*DISPMANX_CALLBACK_FUNC_T)(DISPMANX_UPDATE_HANDLE_T u,
void *arg);
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>
12 years ago
/* from /opt/vc/include/interface/vmcs_host/vc_dispmanx.h */
static inline int
vc_dispmanx_rect_set(VC_RECT_T *rect, uint32_t x_offset, uint32_t y_offset,
uint32_t width, uint32_t height)
{
rect->x = x_offset;
rect->y = y_offset;
rect->width = width;
rect->height = height;
return 0;
}
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>
12 years ago
static inline DISPMANX_RESOURCE_HANDLE_T
vc_dispmanx_resource_create(VC_IMAGE_TYPE_T type, uint32_t width,
uint32_t height, uint32_t *native_image_handle)
{
return DISPMANX_NO_HANDLE;
}
static inline int
vc_dispmanx_resource_write_data(DISPMANX_RESOURCE_HANDLE_T res,
VC_IMAGE_TYPE_T src_type,
int src_pitch,
void *src_address,
const VC_RECT_T *rect)
{
return -1;
}
static inline int
vc_dispmanx_resource_write_data_rect(DISPMANX_RESOURCE_HANDLE_T handle,
VC_IMAGE_TYPE_T src_type,
int src_pitch,
void *src_address,
const VC_RECT_T *src_rect,
uint32_t dst_x,
uint32_t dst_y)
{
return -1;
}
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
static inline int
vc_dispmanx_resource_read_data(DISPMANX_RESOURCE_HANDLE_T handle,
const VC_RECT_T *p_rect,
void *dst_address,
uint32_t dst_pitch)
{
return -1;
}
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>
12 years ago
static inline int
vc_dispmanx_resource_delete(DISPMANX_RESOURCE_HANDLE_T res)
{
return -1;
}
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>
12 years ago
static inline DISPMANX_DISPLAY_HANDLE_T
vc_dispmanx_display_open(uint32_t device)
{
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>
12 years ago
return DISPMANX_NO_HANDLE;
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>
12 years ago
}
static inline int
vc_dispmanx_display_close(DISPMANX_DISPLAY_HANDLE_T display)
{
return -1;
}
static inline int
vc_dispmanx_display_get_info(DISPMANX_DISPLAY_HANDLE_T display,
DISPMANX_MODEINFO_T *pinfo)
{
return -1;
}
static inline DISPMANX_UPDATE_HANDLE_T
vc_dispmanx_update_start(int32_t priority)
{
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>
12 years ago
return DISPMANX_NO_HANDLE;
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>
12 years ago
}
static inline DISPMANX_ELEMENT_HANDLE_T
vc_dispmanx_element_add(DISPMANX_UPDATE_HANDLE_T update,
DISPMANX_DISPLAY_HANDLE_T display,
int32_t layer,
const VC_RECT_T *dest_rect,
DISPMANX_RESOURCE_HANDLE_T src,
const VC_RECT_T *src_rect,
DISPMANX_PROTECTION_T protection,
VC_DISPMANX_ALPHA_T *alpha,
DISPMANX_CLAMP_T *clamp,
DISPMANX_TRANSFORM_T transform)
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>
12 years ago
{
return DISPMANX_NO_HANDLE;
}
static inline int
vc_dispmanx_element_change_source(DISPMANX_UPDATE_HANDLE_T update,
DISPMANX_ELEMENT_HANDLE_T element,
DISPMANX_RESOURCE_HANDLE_T src)
{
return -1;
}
static inline int
vc_dispmanx_element_modified(DISPMANX_UPDATE_HANDLE_T update,
DISPMANX_ELEMENT_HANDLE_T element,
const VC_RECT_T *rect)
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>
12 years ago
{
return -1;
}
static inline int
vc_dispmanx_element_remove(DISPMANX_UPDATE_HANDLE_T update,
DISPMANX_ELEMENT_HANDLE_T element)
{
return -1;
}
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>
12 years ago
static inline int
vc_dispmanx_update_submit(DISPMANX_UPDATE_HANDLE_T update,
DISPMANX_CALLBACK_FUNC_T cb_func, void *cb_arg)
{
return -1;
}
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>
12 years ago
static inline int
vc_dispmanx_update_submit_sync(DISPMANX_UPDATE_HANDLE_T update)
{
return -1;
}
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>
12 years ago
static inline int
vc_dispmanx_element_change_attributes(DISPMANX_UPDATE_HANDLE_T update,
DISPMANX_ELEMENT_HANDLE_T element,
uint32_t change_flags,
int32_t layer,
uint8_t opacity,
const VC_RECT_T *dest_rect,
const VC_RECT_T *src_rect,
DISPMANX_RESOURCE_HANDLE_T mask,
VC_IMAGE_TRANSFORM_T transform)
{
return -1;
}
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
static inline int
vc_dispmanx_snapshot(DISPMANX_DISPLAY_HANDLE_T display,
DISPMANX_RESOURCE_HANDLE_T snapshot_resource,
VC_IMAGE_TRANSFORM_T transform)
{
return -1;
}
struct wl_resource;
static inline DISPMANX_RESOURCE_HANDLE_T
vc_dispmanx_get_handle_from_wl_buffer(struct wl_resource *_buffer)
{
return DISPMANX_NO_HANDLE;
}
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>
12 years ago
/* from /opt/vc/include/EGL/eglplatform.h */
typedef struct {
DISPMANX_ELEMENT_HANDLE_T element;
int width;
int height;
} EGL_DISPMANX_WINDOW_T;
#endif /* RPI_BCM_STUBS */