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

576 lines
15 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>
13 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>
13 years ago
*
* Permission is hereby granted, free of charge, to any person obtaining
* a copy of this software and associated documentation files (the
* "Software"), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sublicense, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial
* portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
*/
#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>
13 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>
13 years ago
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <libudev.h>
#ifdef HAVE_BCM_HOST
# include <bcm_host.h>
#else
# include "rpi-bcm-stubs.h"
#endif
#include "shared/helpers.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>
13 years ago
#include "compositor.h"
#include "rpi-renderer.h"
#include "launcher-util.h"
#include "libinput-seat.h"
compositor: set presentation.presented flags Change weston_output_finish_frame() signature so that backends are required to set the flags, that will be reported on the Presentation 'presented' event. This is meant for output-wide feedback flags. Flags that vary per wl_surface are subject for the following patch. All start_repaint_loop functions use the special private flag PRESENTATION_FEEDBACK_INVALID to mark, that this call of weston_output_finish_frame() cannot trigger the 'presented' event. If it does, we now hit an assert, and should then investigate why a fake update triggered Presentation feedback. DRM: Page flip is always vsync'd, and always gets the completion timestamp from the kernel which should correspond well to hardware. Completion is triggered by the kernel/hardware. Vblank handler is only used with the broken planes path, therefore do not report VSYNC, because we cannot guarantee all the planes updated at the same time. We cannot set the INVALID, because it would abort the compositor if the broken planes path was ever used. This is a hack that will get fixed with nuclear pageflip support in the future. fbdev: No vsync, update done by copy, no completion event from hardware, and completion time is totally fake. headless: No real output to update. RDP: Guessing that maybe no vsync, fake time, and copy make sense (pixels sent over network). Also no event that the pixels have been shown? RPI: Presumably Dispmanx updates are vsync'd. We get a completion event from the driver, but need to read the clock ourselves, so the completion time is somewhat unreliable. Zero-copy flag not implemented though it would be theoretically possible with EGL clients (zero-copy is a per-surface flag anyway, so in this patch). Wayland: No information how the host compositor is doing updates, so make a safe guess without assuming vsync or hardware completion event. While we do get some timestamp from the host compositor, it is not the completion time. Would need to hook to the Presentation extension of the host compositor to get more accurate flags. X11: No idea about vsync, completion event, or copying. Also the timestamp is a fake. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
10 years ago
#include "presentation_timing-server-protocol.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>
13 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>
13 years ago
#if 0
#define DBG(...) \
weston_log(__VA_ARGS__)
#else
#define DBG(...) do {} while (0)
#endif
struct rpi_backend;
rpi: Dispmanx elements as planes, completion callback Dispmanx elements are like hardware overlays. Assign one weston_surface to each overlay created, and the VideoCore will composite it on screen. The maximum number of elements is configurable via the command line. Specifying zero will disable the overlays (planes/elements) altogether, and use only GLESv2 compositing. You need an up-to-date Raspberry Pi firmware for: - vc_dispmanx_resource_create(), that will also take stride. Otherwise surfaces ending up in elements may show up as corrupted. - off-line compositing support. The on-line compositing of elements cannot handle too many elements. Look for the comments around DEFAULT_MAX_PLANES in the code. Elements must be double-buffered to avoid tearing. Therefore two buffers (Dispmanx resources) are allocated for each element. A command line option is added to allow single-buffering instead to save memory, with the risk of tearing. The page flip timer is replaced with the Dispmanx update completion callback. The callback is executed in a separate thread, therefore a pipe is set up to integrate properly with Weston core. If not disabled, usually all surfaces are assigned into planes, and nothing is composited in GLESv2. Planes do not support surface transformations though, so compositing will automatically switch the necessary surfaces to GLESv2 compositing as needed. Switching between GLESv2 and elements may cause transient visual glitches and jerks. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
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>
13 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>
13 years ago
struct rpi_output {
struct rpi_backend *backend;
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
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>
13 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>
13 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>
13 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>
13 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_backend {
struct weston_backend base;
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>
13 years ago
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>
13 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>
13 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_backend *
to_rpi_backend(struct weston_compositor *c)
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
{
return container_of(c->backend, struct rpi_backend, 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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 years ago
static int
rpi_flippipe_init(struct rpi_flippipe *flippipe, struct rpi_output *output)
{
struct weston_compositor *compositor = output->backend->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>
13 years ago
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 = compositor->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>
13 years ago
loop = wl_display_get_event_loop(compositor->wl_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>
13 years ago
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;
compositor: set presentation.presented flags Change weston_output_finish_frame() signature so that backends are required to set the flags, that will be reported on the Presentation 'presented' event. This is meant for output-wide feedback flags. Flags that vary per wl_surface are subject for the following patch. All start_repaint_loop functions use the special private flag PRESENTATION_FEEDBACK_INVALID to mark, that this call of weston_output_finish_frame() cannot trigger the 'presented' event. If it does, we now hit an assert, and should then investigate why a fake update triggered Presentation feedback. DRM: Page flip is always vsync'd, and always gets the completion timestamp from the kernel which should correspond well to hardware. Completion is triggered by the kernel/hardware. Vblank handler is only used with the broken planes path, therefore do not report VSYNC, because we cannot guarantee all the planes updated at the same time. We cannot set the INVALID, because it would abort the compositor if the broken planes path was ever used. This is a hack that will get fixed with nuclear pageflip support in the future. fbdev: No vsync, update done by copy, no completion event from hardware, and completion time is totally fake. headless: No real output to update. RDP: Guessing that maybe no vsync, fake time, and copy make sense (pixels sent over network). Also no event that the pixels have been shown? RPI: Presumably Dispmanx updates are vsync'd. We get a completion event from the driver, but need to read the clock ourselves, so the completion time is somewhat unreliable. Zero-copy flag not implemented though it would be theoretically possible with EGL clients (zero-copy is a per-surface flag anyway, so in this patch). Wayland: No information how the host compositor is doing updates, so make a safe guess without assuming vsync or hardware completion event. While we do get some timestamp from the host compositor, it is not the completion time. Would need to hook to the Presentation extension of the host compositor to get more accurate flags. X11: No idea about vsync, completion event, or copying. Also the timestamp is a fake. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
10 years ago
/* XXX: do a phony dispmanx update and trigger on its completion? */
weston_compositor_read_presentation_clock(output->compositor, &ts);
compositor: set presentation.presented flags Change weston_output_finish_frame() signature so that backends are required to set the flags, that will be reported on the Presentation 'presented' event. This is meant for output-wide feedback flags. Flags that vary per wl_surface are subject for the following patch. All start_repaint_loop functions use the special private flag PRESENTATION_FEEDBACK_INVALID to mark, that this call of weston_output_finish_frame() cannot trigger the 'presented' event. If it does, we now hit an assert, and should then investigate why a fake update triggered Presentation feedback. DRM: Page flip is always vsync'd, and always gets the completion timestamp from the kernel which should correspond well to hardware. Completion is triggered by the kernel/hardware. Vblank handler is only used with the broken planes path, therefore do not report VSYNC, because we cannot guarantee all the planes updated at the same time. We cannot set the INVALID, because it would abort the compositor if the broken planes path was ever used. This is a hack that will get fixed with nuclear pageflip support in the future. fbdev: No vsync, update done by copy, no completion event from hardware, and completion time is totally fake. headless: No real output to update. RDP: Guessing that maybe no vsync, fake time, and copy make sense (pixels sent over network). Also no event that the pixels have been shown? RPI: Presumably Dispmanx updates are vsync'd. We get a completion event from the driver, but need to read the clock ourselves, so the completion time is somewhat unreliable. Zero-copy flag not implemented though it would be theoretically possible with EGL clients (zero-copy is a per-surface flag anyway, so in this patch). Wayland: No information how the host compositor is doing updates, so make a safe guess without assuming vsync or hardware completion event. While we do get some timestamp from the host compositor, it is not the completion time. Would need to hook to the Presentation extension of the host compositor to get more accurate flags. X11: No idea about vsync, completion event, or copying. Also the timestamp is a fake. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
10 years ago
weston_output_finish_frame(output, &ts, PRESENTATION_FEEDBACK_INVALID);
}
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>
13 years ago
rpi_output_repaint(struct weston_output *base, pixman_region32_t *damage)
{
struct rpi_output *output = to_rpi_output(base);
struct weston_compositor *compositor = output->backend->compositor;
struct weston_plane *primary_plane = &compositor->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>
13 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>
13 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>
13 years ago
rpi_renderer_set_update_handle(&output->base, update);
compositor->renderer->repaint_output(&output->base, damage);
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
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>
13 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>
13 years ago
{
compositor: set presentation.presented flags Change weston_output_finish_frame() signature so that backends are required to set the flags, that will be reported on the Presentation 'presented' event. This is meant for output-wide feedback flags. Flags that vary per wl_surface are subject for the following patch. All start_repaint_loop functions use the special private flag PRESENTATION_FEEDBACK_INVALID to mark, that this call of weston_output_finish_frame() cannot trigger the 'presented' event. If it does, we now hit an assert, and should then investigate why a fake update triggered Presentation feedback. DRM: Page flip is always vsync'd, and always gets the completion timestamp from the kernel which should correspond well to hardware. Completion is triggered by the kernel/hardware. Vblank handler is only used with the broken planes path, therefore do not report VSYNC, because we cannot guarantee all the planes updated at the same time. We cannot set the INVALID, because it would abort the compositor if the broken planes path was ever used. This is a hack that will get fixed with nuclear pageflip support in the future. fbdev: No vsync, update done by copy, no completion event from hardware, and completion time is totally fake. headless: No real output to update. RDP: Guessing that maybe no vsync, fake time, and copy make sense (pixels sent over network). Also no event that the pixels have been shown? RPI: Presumably Dispmanx updates are vsync'd. We get a completion event from the driver, but need to read the clock ourselves, so the completion time is somewhat unreliable. Zero-copy flag not implemented though it would be theoretically possible with EGL clients (zero-copy is a per-surface flag anyway, so in this patch). Wayland: No information how the host compositor is doing updates, so make a safe guess without assuming vsync or hardware completion event. While we do get some timestamp from the host compositor, it is not the completion time. Would need to hook to the Presentation extension of the host compositor to get more accurate flags. X11: No idea about vsync, completion event, or copying. Also the timestamp is a fake. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
10 years ago
uint32_t flags = PRESENTATION_FEEDBACK_KIND_VSYNC |
PRESENTATION_FEEDBACK_KIND_HW_COMPLETION;
DBG("frame update complete(%ld.%09ld)\n",
(long)stamp->tv_sec, (long)stamp->tv_nsec);
rpi_renderer_finish_frame(&output->base);
compositor: set presentation.presented flags Change weston_output_finish_frame() signature so that backends are required to set the flags, that will be reported on the Presentation 'presented' event. This is meant for output-wide feedback flags. Flags that vary per wl_surface are subject for the following patch. All start_repaint_loop functions use the special private flag PRESENTATION_FEEDBACK_INVALID to mark, that this call of weston_output_finish_frame() cannot trigger the 'presented' event. If it does, we now hit an assert, and should then investigate why a fake update triggered Presentation feedback. DRM: Page flip is always vsync'd, and always gets the completion timestamp from the kernel which should correspond well to hardware. Completion is triggered by the kernel/hardware. Vblank handler is only used with the broken planes path, therefore do not report VSYNC, because we cannot guarantee all the planes updated at the same time. We cannot set the INVALID, because it would abort the compositor if the broken planes path was ever used. This is a hack that will get fixed with nuclear pageflip support in the future. fbdev: No vsync, update done by copy, no completion event from hardware, and completion time is totally fake. headless: No real output to update. RDP: Guessing that maybe no vsync, fake time, and copy make sense (pixels sent over network). Also no event that the pixels have been shown? RPI: Presumably Dispmanx updates are vsync'd. We get a completion event from the driver, but need to read the clock ourselves, so the completion time is somewhat unreliable. Zero-copy flag not implemented though it would be theoretically possible with EGL clients (zero-copy is a per-surface flag anyway, so in this patch). Wayland: No information how the host compositor is doing updates, so make a safe guess without assuming vsync or hardware completion event. While we do get some timestamp from the host compositor, it is not the completion time. Would need to hook to the Presentation extension of the host compositor to get more accurate flags. X11: No idea about vsync, completion event, or copying. Also the timestamp is a fake. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
10 years ago
weston_output_finish_frame(&output->base, stamp, flags);
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
}
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>
13 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>
13 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>
13 years ago
weston_output_destroy(&output->base);
vc_dispmanx_display_close(output->display);
free(output);
}
static int
rpi_output_create(struct rpi_backend *backend, 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>
13 years ago
{
struct rpi_output *output;
DISPMANX_MODEINFO_T modeinfo;
int ret;
float mm_width, mm_height;
output = zalloc(sizeof *output);
if (output == 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>
13 years ago
return -1;
output->backend = backend;
output->single_buffer = backend->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>
13 years ago
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>
13 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>
13 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>
13 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>
13 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>
13 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>
13 years ago
output->base.subpixel = WL_OUTPUT_SUBPIXEL_UNKNOWN;
output->base.make = "unknown";
output->base.model = "unknown";
output->base.name = strdup("rpi");
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
/* guess 96 dpi */
mm_width = modeinfo.width * (25.4f / 96.0f);
mm_height = modeinfo.height * (25.4f / 96.0f);
weston_output_init(&output->base, backend->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>
13 years ago
0, 0, round(mm_width), round(mm_height),
transform, 1);
if (rpi_renderer_output_create(&output->base, output->display) < 0)
goto out_output;
weston_compositor_add_output(backend->compositor, &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>
13 years ago
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",
weston_transform_to_string(output->base.transform));
if (!strncmp(weston_transform_to_string(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>
13 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>
13 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>
13 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>
13 years ago
out_free:
free(output);
return -1;
}
static void
rpi_backend_destroy(struct weston_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>
13 years ago
{
struct rpi_backend *backend = to_rpi_backend(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>
13 years ago
udev_input_destroy(&backend->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>
13 years ago
/* destroys outputs, too */
weston_compositor_shutdown(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>
13 years ago
weston_launcher_destroy(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>
13 years ago
bcm_host_deinit();
free(backend);
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
}
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>
13 years ago
{
struct weston_compositor *compositor = data;
struct rpi_backend *backend = to_rpi_backend(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>
13 years ago
struct weston_output *output;
if (compositor->session_active) {
weston_log("activating session\n");
compositor->state = backend->prev_state;
weston_compositor_damage_all(compositor);
udev_input_enable(&backend->input);
} else {
weston_log("deactivating session\n");
udev_input_disable(&backend->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>
13 years ago
backend->prev_state = compositor->state;
weston_compositor_offscreen(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>
13 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>
13 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->output_list, link) {
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
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>
13 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>
13 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>
13 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>
13 years ago
};
static struct rpi_backend *
rpi_backend_create(struct weston_compositor *compositor,
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>
13 years ago
{
struct rpi_backend *backend;
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
weston_log("initializing Raspberry Pi backend\n");
backend = zalloc(sizeof *backend);
if (backend == 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>
13 years ago
return NULL;
if (weston_compositor_set_presentation_clock_software(
compositor) < 0)
goto out_compositor;
backend->udev = udev_new();
if (backend->udev == 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>
13 years ago
weston_log("Failed to initialize udev context.\n");
goto out_compositor;
}
backend->session_listener.notify = session_notify;
wl_signal_add(&compositor->session_signal,
&backend->session_listener);
compositor->launcher =
weston_launcher_connect(compositor, param->tty, "seat0", false);
if (!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>
13 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>
13 years ago
}
backend->base.destroy = rpi_backend_destroy;
backend->base.restore = rpi_restore;
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
backend->compositor = compositor;
backend->prev_state = WESTON_COMPOSITOR_ACTIVE;
backend->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>
13 years ago
weston_log("Dispmanx planes are %s buffered.\n",
backend->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>
13 years ago
weston_setup_vt_switch_bindings(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>
13 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>
13 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>
13 years ago
bcm_host_init();
if (rpi_renderer_create(compositor, &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>
13 years ago
if (rpi_output_create(backend, param->output_transform) < 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>
13 years ago
if (udev_input_init(&backend->input,
compositor,
backend->udev, "seat0") != 0) {
weston_log("Failed to initialize udev input.\n");
goto out_launcher;
}
compositor->backend = &backend->base;
return backend;
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
out_launcher:
weston_launcher_destroy(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>
13 years ago
out_udev:
udev_unref(backend->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>
13 years ago
out_compositor:
weston_compositor_shutdown(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>
13 years ago
bcm_host_deinit();
free(backend);
rpi: a backend for Raspberry Pi Add a new backend for the Raspberry Pi. This backend uses the DispmanX API to initialise the display, and create an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer". No X server is involved. All compositing happens through GLESv2. The created EGLSurface is specifically configured as buffer content preserving, otherwise Weston wouuld show only the latest damage and everything else was black. This may be sub-optimal, since we are not alternating between two buffers, like the DRM backend is, and content preserving may imply a fullscreen copy on each frame. Page flips are not properly hooked up yet. The display update will block, and we use a timer to call weston_output_finish_frame(), just like the x11 backend does. This backend handles the VT and tty just like the DRM backend does. While VT switching works in theory, the display output seems to be frozen while switched away from Weston. You can still switch back. Seats and connectors cannot be explicitly specified, and multiple seats are not expected. Udev is used to find the input devices. Input devices are opened directly, weston-launch is not supported at this time. You may need to confirm that your pi user has access to input device nodes. The Raspberry Pi backend is built by default. It can be build-tested without the Raspberry Pi headers and libraries, because we provide stubs in rpi-bcm-stubs.h, but such resulting binary is non-functional. If using stubs, the backend is built but not installed. VT and tty handling, and udev related code are pretty much copied from the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is copied from the headers on Raspberry Pi, including their copyright notice, and modified. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
return NULL;
}
WL_EXPORT int
backend_init(struct weston_compositor *compositor,
int *argc, char *argv[],
struct weston_config *config,
struct weston_backend_config *config_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>
13 years ago
{
const char *transform = "normal";
struct rpi_backend *b;
rpi: Dispmanx elements as planes, completion callback Dispmanx elements are like hardware overlays. Assign one weston_surface to each overlay created, and the VideoCore will composite it on screen. The maximum number of elements is configurable via the command line. Specifying zero will disable the overlays (planes/elements) altogether, and use only GLESv2 compositing. You need an up-to-date Raspberry Pi firmware for: - vc_dispmanx_resource_create(), that will also take stride. Otherwise surfaces ending up in elements may show up as corrupted. - off-line compositing support. The on-line compositing of elements cannot handle too many elements. Look for the comments around DEFAULT_MAX_PLANES in the code. Elements must be double-buffered to avoid tearing. Therefore two buffers (Dispmanx resources) are allocated for each element. A command line option is added to allow single-buffering instead to save memory, with the risk of tearing. The page flip timer is replaced with the Dispmanx update completion callback. The callback is executed in a separate thread, therefore a pipe is set up to integrate properly with Weston core. If not disabled, usually all surfaces are assigned into planes, and nothing is composited in GLESv2. Planes do not support surface transformations though, so compositing will automatically switch the necessary surfaces to GLESv2 compositing as needed. Switching between GLESv2 and elements may cause transient visual glitches and jerks. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
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>
13 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>
13 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>
13 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>
13 years ago
};
parse_options(rpi_options, ARRAY_LENGTH(rpi_options), argc, argv);
if (weston_parse_transform(transform, &param.output_transform) < 0)
weston_log("invalid transform \"%s\"\n", transform);
b = rpi_backend_create(compositor, &param);
if (b == NULL)
return -1;
return 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>
13 years ago
}