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/compositor-rpi.c

611 lines
16 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 © 2008-2011 Kristian Høgsberg
* Copyright © 2011 Intel Corporation
* Copyright © 2012-2013 Raspberry Pi Foundation
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
*
* Permission to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
* that the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of the copyright holders not be used in
* advertising or publicity pertaining to distribution of the software
* without specific, written prior permission. The copyright holders make
* no representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
* SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
* SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
* RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
* CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include "config.h"
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
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>
#include <sys/time.h>
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
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/input.h>
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
#include <libudev.h>
#ifdef HAVE_BCM_HOST
# include <bcm_host.h>
#else
# include "rpi-bcm-stubs.h"
#endif
#include "compositor.h"
#include "rpi-renderer.h"
#include "launcher-util.h"
#include "udev-input.h"
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
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
#if 0
#define DBG(...) \
weston_log(__VA_ARGS__)
#else
#define DBG(...) do {} while (0)
#endif
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
struct rpi_compositor;
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
struct rpi_output;
struct rpi_flippipe {
int readfd;
int writefd;
clockid_t clk_id;
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
struct wl_event_source *source;
};
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
struct rpi_output {
struct rpi_compositor *compositor;
struct weston_output base;
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
int single_buffer;
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
struct weston_mode mode;
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
struct rpi_flippipe flippipe;
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_DISPLAY_HANDLE_T display;
};
struct rpi_seat {
struct weston_seat base;
struct wl_list devices_list;
struct udev_monitor *udev_monitor;
struct wl_event_source *udev_monitor_source;
char *seat_id;
};
struct rpi_compositor {
struct weston_compositor base;
uint32_t prev_state;
struct udev *udev;
struct udev_input input;
struct wl_listener session_listener;
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
int single_buffer;
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 struct rpi_output *
to_rpi_output(struct weston_output *base)
{
return container_of(base, struct rpi_output, base);
}
static inline struct rpi_seat *
to_rpi_seat(struct weston_seat *base)
{
return container_of(base, struct rpi_seat, base);
}
static inline struct rpi_compositor *
to_rpi_compositor(struct weston_compositor *base)
{
return container_of(base, struct rpi_compositor, base);
}
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 void
rpi_flippipe_update_complete(DISPMANX_UPDATE_HANDLE_T update, void *data)
{
/* This function runs in a different thread. */
struct rpi_flippipe *flippipe = data;
struct timespec ts;
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
ssize_t ret;
/* manufacture flip completion timestamp */
clock_gettime(flippipe->clk_id, &ts);
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
ret = write(flippipe->writefd, &ts, sizeof ts);
if (ret != sizeof ts)
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
weston_log("ERROR: %s failed to write, ret %zd, errno %d\n",
__func__, ret, errno);
}
static int
rpi_dispmanx_update_submit(DISPMANX_UPDATE_HANDLE_T update,
struct rpi_output *output)
{
/*
* The callback registered here will eventually be called
* in a different thread context. Therefore we cannot call
* the usual functions from rpi_flippipe_update_complete().
* Instead, we have a pipe for passing the message from the
* thread, waking up the Weston main event loop, calling
* rpi_flippipe_handler(), and then ending up in
* rpi_output_update_complete() in the main thread context,
* where we can do the frame finishing work.
*/
return vc_dispmanx_update_submit(update, rpi_flippipe_update_complete,
&output->flippipe);
}
static void
rpi_output_update_complete(struct rpi_output *output,
const struct timespec *stamp);
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 int
rpi_flippipe_handler(int fd, uint32_t mask, void *data)
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
{
struct rpi_output *output = data;
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
ssize_t ret;
struct timespec ts;
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
if (mask != WL_EVENT_READABLE)
weston_log("ERROR: unexpected mask 0x%x in %s\n",
mask, __func__);
ret = read(fd, &ts, sizeof ts);
if (ret != sizeof ts) {
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
weston_log("ERROR: %s failed to read, ret %zd, errno %d\n",
__func__, ret, errno);
}
rpi_output_update_complete(output, &ts);
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;
}
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 int
rpi_flippipe_init(struct rpi_flippipe *flippipe, struct rpi_output *output)
{
struct wl_event_loop *loop;
int fd[2];
if (pipe2(fd, O_CLOEXEC) == -1)
return -1;
flippipe->readfd = fd[0];
flippipe->writefd = fd[1];
flippipe->clk_id = output->compositor->base.presentation_clock;
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
loop = wl_display_get_event_loop(output->compositor->base.wl_display);
flippipe->source = wl_event_loop_add_fd(loop, flippipe->readfd,
WL_EVENT_READABLE,
rpi_flippipe_handler, output);
if (!flippipe->source) {
close(flippipe->readfd);
close(flippipe->writefd);
return -1;
}
return 0;
}
static void
rpi_flippipe_release(struct rpi_flippipe *flippipe)
{
wl_event_source_remove(flippipe->source);
close(flippipe->readfd);
close(flippipe->writefd);
}
static void
rpi_output_start_repaint_loop(struct weston_output *output)
{
struct timespec ts;
clock_gettime(output->compositor->presentation_clock, &ts);
weston_output_finish_frame(output, &ts);
}
static int
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
rpi_output_repaint(struct weston_output *base, pixman_region32_t *damage)
{
struct rpi_output *output = to_rpi_output(base);
struct rpi_compositor *compositor = output->compositor;
struct weston_plane *primary_plane = &compositor->base.primary_plane;
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
DISPMANX_UPDATE_HANDLE_T update;
DBG("frame update start\n");
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
/* Update priority higher than in rpi-renderer's
* output destroy function, see rpi_output_destroy().
*/
update = vc_dispmanx_update_start(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
rpi_renderer_set_update_handle(&output->base, update);
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
compositor->base.renderer->repaint_output(&output->base, damage);
pixman_region32_subtract(&primary_plane->damage,
&primary_plane->damage, damage);
/* schedule callback to rpi_output_update_complete() */
rpi_dispmanx_update_submit(update, output);
DBG("frame update submitted\n");
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 void
rpi_output_update_complete(struct rpi_output *output,
const struct timespec *stamp)
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
{
DBG("frame update complete(%ld.%09ld)\n",
(long)stamp->tv_sec, (long)stamp->tv_nsec);
rpi_renderer_finish_frame(&output->base);
weston_output_finish_frame(&output->base, stamp);
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 void
rpi_output_destroy(struct weston_output *base)
{
struct rpi_output *output = to_rpi_output(base);
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
DBG("%s\n", __func__);
rpi_renderer_output_destroy(base);
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
/* rpi_renderer_output_destroy() will schedule a removal of
* all Dispmanx Elements, and wait for the update to complete.
* Assuming updates are sequential, the wait should guarantee,
* that any pending rpi_flippipe_update_complete() callbacks
* have happened already. Therefore we can destroy the flippipe
* now.
*/
rpi_flippipe_release(&output->flippipe);
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
weston_output_destroy(&output->base);
vc_dispmanx_display_close(output->display);
free(output);
}
static const char *transform_names[] = {
[WL_OUTPUT_TRANSFORM_NORMAL] = "normal",
[WL_OUTPUT_TRANSFORM_90] = "90",
[WL_OUTPUT_TRANSFORM_180] = "180",
[WL_OUTPUT_TRANSFORM_270] = "270",
[WL_OUTPUT_TRANSFORM_FLIPPED] = "flipped",
[WL_OUTPUT_TRANSFORM_FLIPPED_90] = "flipped-90",
[WL_OUTPUT_TRANSFORM_FLIPPED_180] = "flipped-180",
[WL_OUTPUT_TRANSFORM_FLIPPED_270] = "flipped-270",
};
static int
str2transform(const char *name)
{
unsigned i;
for (i = 0; i < ARRAY_LENGTH(transform_names); i++)
if (strcmp(name, transform_names[i]) == 0)
return i;
return -1;
}
static const char *
transform2str(uint32_t output_transform)
{
if (output_transform >= ARRAY_LENGTH(transform_names))
return "<illegal value>";
return transform_names[output_transform];
}
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 int
rpi_output_create(struct rpi_compositor *compositor, uint32_t transform)
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
{
struct rpi_output *output;
DISPMANX_MODEINFO_T modeinfo;
int ret;
float mm_width, mm_height;
output = calloc(1, sizeof *output);
if (!output)
return -1;
output->compositor = compositor;
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
output->single_buffer = compositor->single_buffer;
if (rpi_flippipe_init(&output->flippipe, output) < 0) {
weston_log("Creating message pipe failed.\n");
goto out_free;
}
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
output->display = vc_dispmanx_display_open(DISPMANX_ID_HDMI);
if (!output->display) {
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
weston_log("Failed to open dispmanx HDMI display.\n");
goto out_pipe;
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
}
ret = vc_dispmanx_display_get_info(output->display, &modeinfo);
if (ret < 0) {
weston_log("Failed to get display mode information.\n");
goto out_dmx_close;
}
output->base.start_repaint_loop = rpi_output_start_repaint_loop;
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
output->base.repaint = rpi_output_repaint;
output->base.destroy = rpi_output_destroy;
output->base.assign_planes = NULL;
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
output->base.set_backlight = NULL;
output->base.set_dpms = NULL;
output->base.switch_mode = NULL;
/* XXX: use tvservice to get information from and control the
* HDMI and SDTV outputs. See:
* /opt/vc/include/interface/vmcs_host/vc_tvservice.h
*/
/* only one static mode in list */
output->mode.flags =
WL_OUTPUT_MODE_CURRENT | WL_OUTPUT_MODE_PREFERRED;
output->mode.width = modeinfo.width;
output->mode.height = modeinfo.height;
output->mode.refresh = 60000;
wl_list_init(&output->base.mode_list);
wl_list_insert(&output->base.mode_list, &output->mode.link);
output->base.current_mode = &output->mode;
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
output->base.subpixel = WL_OUTPUT_SUBPIXEL_UNKNOWN;
output->base.make = "unknown";
output->base.model = "unknown";
/* guess 96 dpi */
mm_width = modeinfo.width * (25.4f / 96.0f);
mm_height = modeinfo.height * (25.4f / 96.0f);
weston_output_init(&output->base, &compositor->base,
0, 0, round(mm_width), round(mm_height),
transform, 1);
if (rpi_renderer_output_create(&output->base, output->display) < 0)
goto out_output;
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
wl_list_insert(compositor->base.output_list.prev, &output->base.link);
weston_log("Raspberry Pi HDMI output %dx%d px\n",
output->mode.width, output->mode.height);
weston_log_continue(STAMP_SPACE "guessing %d Hz and 96 dpi\n",
output->mode.refresh / 1000);
weston_log_continue(STAMP_SPACE "orientation: %s\n",
transform2str(output->base.transform));
if (!strncmp(transform2str(output->base.transform), "flipped", 7))
weston_log("warning: flipped output transforms may not work\n");
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 0;
out_output:
weston_output_destroy(&output->base);
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
out_dmx_close:
vc_dispmanx_display_close(output->display);
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
out_pipe:
rpi_flippipe_release(&output->flippipe);
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
out_free:
free(output);
return -1;
}
static void
rpi_compositor_destroy(struct weston_compositor *base)
{
struct rpi_compositor *compositor = to_rpi_compositor(base);
udev_input_destroy(&compositor->input);
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
/* destroys outputs, too */
weston_compositor_shutdown(&compositor->base);
weston_launcher_destroy(compositor->base.launcher);
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
bcm_host_deinit();
free(compositor);
}
static void
session_notify(struct wl_listener *listener, void *data)
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
{
struct rpi_compositor *compositor = data;
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
struct weston_output *output;
if (compositor->base.session_active) {
weston_log("activating session\n");
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
compositor->base.state = compositor->prev_state;
weston_compositor_damage_all(&compositor->base);
udev_input_enable(&compositor->input);
} else {
weston_log("deactivating session\n");
udev_input_disable(&compositor->input);
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
compositor->prev_state = compositor->base.state;
weston_compositor_offscreen(&compositor->base);
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
/* If we have a repaint scheduled (either from a
* pending pageflip or the idle handler), make sure we
* cancel that so we don't try to pageflip when we're
* vt switched away. The OFFSCREEN state will prevent
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
* further attemps at repainting. When we switch
* back, we schedule a repaint, which will process
* pending frame callbacks. */
wl_list_for_each(output,
&compositor->base.output_list, link) {
output->repaint_needed = 0;
}
};
}
static void
rpi_restore(struct weston_compositor *compositor)
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
{
weston_launcher_restore(compositor->launcher);
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 void
switch_vt_binding(struct weston_seat *seat, uint32_t time, uint32_t key, void *data)
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
{
struct weston_compositor *compositor = data;
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
weston_launcher_activate_vt(compositor->launcher, key - KEY_F1 + 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
}
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
struct rpi_parameters {
int tty;
struct rpi_renderer_parameters renderer;
uint32_t output_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
};
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 struct weston_compositor *
rpi_compositor_create(struct wl_display *display, int *argc, char *argv[],
struct weston_config *config,
struct rpi_parameters *param)
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
{
struct rpi_compositor *compositor;
uint32_t key;
weston_log("initializing Raspberry Pi backend\n");
compositor = calloc(1, sizeof *compositor);
if (compositor == NULL)
return NULL;
if (weston_compositor_init(&compositor->base, display, argc, argv,
config) < 0)
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
goto out_free;
if (weston_compositor_set_presentation_clock_software(
&compositor->base) < 0)
goto out_compositor;
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
compositor->udev = udev_new();
if (compositor->udev == NULL) {
weston_log("Failed to initialize udev context.\n");
goto out_compositor;
}
compositor->session_listener.notify = session_notify;
wl_signal_add(&compositor->base.session_signal,
&compositor ->session_listener);
compositor->base.launcher =
weston_launcher_connect(&compositor->base, param->tty, "seat0");
if (!compositor->base.launcher) {
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
weston_log("Failed to initialize tty.\n");
goto out_udev;
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
}
compositor->base.destroy = rpi_compositor_destroy;
compositor->base.restore = rpi_restore;
compositor->prev_state = WESTON_COMPOSITOR_ACTIVE;
compositor->single_buffer = param->renderer.single_buffer;
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
weston_log("Dispmanx planes are %s buffered.\n",
compositor->single_buffer ? "single" : "double");
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
for (key = KEY_F1; key < KEY_F9; key++)
weston_compositor_add_key_binding(&compositor->base, key,
MODIFIER_CTRL | MODIFIER_ALT,
switch_vt_binding, compositor);
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
/*
* bcm_host_init() creates threads.
* Therefore we must have all signal handlers set and signals blocked
* before calling it. Otherwise the signals may end in the bcm
* threads and cause the default behaviour there. For instance,
* SIGUSR1 used for VT switching caused Weston to terminate there.
*/
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
bcm_host_init();
if (rpi_renderer_create(&compositor->base, &param->renderer) < 0)
goto out_launcher;
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
if (rpi_output_create(compositor, param->output_transform) < 0)
goto out_renderer;
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
if (udev_input_init(&compositor->input,
&compositor->base,
compositor->udev, "seat0") != 0) {
weston_log("Failed to initialize udev input.\n");
goto out_renderer;
}
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 &compositor->base;
out_renderer:
compositor->base.renderer->destroy(&compositor->base);
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
out_launcher:
weston_launcher_destroy(compositor->base.launcher);
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
out_udev:
udev_unref(compositor->udev);
out_compositor:
weston_compositor_shutdown(&compositor->base);
out_free:
bcm_host_deinit();
free(compositor);
return NULL;
}
WL_EXPORT struct weston_compositor *
backend_init(struct wl_display *display, int *argc, char *argv[],
struct weston_config *config)
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
{
const char *transform = "normal";
int ret;
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
struct rpi_parameters param = {
.tty = 0, /* default to current tty */
.renderer.single_buffer = 0,
.output_transform = WL_OUTPUT_TRANSFORM_NORMAL,
.renderer.opaque_regions = 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
};
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
const struct weston_option rpi_options[] = {
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
{ WESTON_OPTION_INTEGER, "tty", 0, &param.tty },
{ WESTON_OPTION_BOOLEAN, "single-buffer", 0,
&param.renderer.single_buffer },
{ WESTON_OPTION_STRING, "transform", 0, &transform },
{ WESTON_OPTION_BOOLEAN, "opaque-regions", 0,
&param.renderer.opaque_regions },
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
};
parse_options(rpi_options, ARRAY_LENGTH(rpi_options), argc, argv);
ret = str2transform(transform);
if (ret < 0)
weston_log("invalid transform \"%s\"\n", transform);
else
param.output_transform = ret;
return rpi_compositor_create(display, argc, argv, config, &param);
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
}