This patch installs the three header files that define the compositor
plugin interface as well as a pkg-config file. This allows
building weston plugins outside the weston tree. We currently don't make
any guarantees about the plugin API/ABI except that within a stable
branch we won't break it.
libunwind has a dwarf parser and automatically queries the dlinfo
for location of dlopened modules. The resulting backtrace is much
better and includes stack frames in dynamically loaded modules.
krh: Originally submitted for Xorg, adapted for weston:
http://lists.x.org/archives/xorg-devel/2013-February/035493.html
Note this require libunwind at least 1.1 to get the pkg-config files.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Add a frame buffer backend using pixman to render to fbdev.
This has been tested against nouveaufb but nothing else. Much of the code
came straight from the rpi backend (and copyright has been attributed
accordingly).
The behaviour of this backend on less modern frame buffers has yet to be
tested.
The refresh rate is calculated from the frame buffer's metadata. Every frame
is finished in synchrony with the refresh rate.
Frame buffer devices are currently specified on the command line (or using
the default of /dev/fb0); udev could be used in future to enumerate them.
pixman is used for compositing, and a suitable pixman format is built from
the frame buffer's metadata. This doesn't support the full range of
frame buffer formats, but does support varying BPPs of RGBA and ARGB. That
should be enough for now.
The following are not currently supported:
• FOURCC
• Non-packed formats (interleaved, planes, etc.)
• Non-true-colour formats (monochrome, greyscale, etc.)
• Big-endian formats (with component MSBs on the right)
• Non-RGBA and non-ARGB formats
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The Android backend has been fairly unused, since we do not have
projects actively using it. It gets basic build testing as part of the
normal build, but runtime testing it takes a considerable effort, and so
I have not done that in a long time. The code is slowly rotting, and
with new emerging backends it starts to be a burden, since it cannot use
udev, but needs evdev.
Therefore to ease Weston going forward, remove the Android backend. If
someone misses it, it can still be found in the stable 1.0 branch, and
of course resurrected from git history if someone wants to put in the
effort and maintain it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This renderer could be used when there's no graphic accelerator available,
for example in (future) KMS and fbdev backends.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
We want to make sure that the matrix symbols are exported from weston and
that modules get them from there. To do that, we pull matrix.[ch] out of
libshared and back into weston. calibrator now also links to matrix.[ch]
and we add a IN_WESTON define to enable the WL_EXPORT macro when compiled
inside weston.
Fix the following build warnings, and the build failures due to the
warning fixes:
CC libshared_cairo_la-image-loader.lo
image-loader.c:369:1: warning: no previous prototype for 'load_image'
CC x11_backend_la-compositor-x11.lo
compositor-x11.c: In function 'x11_output_set_icon':
compositor-x11.c:396:2: warning: implicit declaration of function 'load_image'
compositor-x11.c:396:8: warning: assignment makes pointer from integer without a cast
CC wayland_backend_la-compositor-wayland.lo
compositor-wayland.c: In function 'create_border':
compositor-wayland.c:97:2: warning: implicit declaration of function 'load_image'
compositor-wayland.c:97:8: warning: assignment makes pointer from integer without a cast
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
We were pulling in cairo and the image loading libraries through libshared.
Split out libshared into a core libshared and a libshared-cairo that
pulls in the extra libraries.
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>
Add a headless backend and a noop renderer, mainly for testing
purposes. Although no rendering is performed with this backend,
this allow some of the code paths inside Weston and shm clients
to be tested without any windowing system or any need for drm
access.
It makes sense to split the interfaces in a text and a input-method
protocol for now (only the text protocol needs to be used in toolkits).
Signed-off-by: Jan Arne Petersen <jpetersen@openismus.com>
We move the EGL and GLES2 output repaint code into a new gles2-render.c
file. The eglMakeCurrent, glViewPort, surface loop etc was duplicated
across all backends, but this patch moves it to a new file.
The workspace manager interface purpose is to provide clients with
control and knowledge about the current workspace state. Initially only
one function and one event exists; moving a surface and state updated
event. A workspace is represented as an index in a 1 dimensional array.
A client keeps track of the state by being broadcasted events when the
state changes, currently limited to current workspace or number of
workspaces available.
A client can send an asynchronous request to the manager asking to move
a surface to workspace identified by an index. It is up to the shell to
actually move it.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This backend has not seen even build testing for months, presumably does
not even compile, and is starting to hinder development a little.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Benjamin Franzke <benjaminfranzke@googlemail.com>
We don't support this anymore. weston requires a setuid helper (such as
weston-launch) to run under kms, and should never run as root itself.
Disabe the setuid warning in configure.ac since we now only install the
minimal weston-launch as setuid.
This is logging functionality for weston compositor.
It handles:
messages coming from libwayland-server from wl_log()
messages from weston itself, from weston_log()
Introduce --log option, to specify log file path on the command line.
When the path is incorrect, or on weston_log_file_destroy(), fall
back to stderr.
We use the selection signal to get a callback when somebody sets a
selection (including the X server proxy) and then copy the contents
of the first mime type. If the selection is cleared (when the client
dies), we set a new selection with that contents.
The patch "compositor-android: fix build flags" started using GCC_CFLAGS
for C++ files, too. That lead to the following warnings when building a
C++ file:
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wmissing-prototypes" is valid
for Ada/C/ObjC but not for C++
Introduce GCC_CXXFLAGS, similar to GCC_CFLAGS, but for C++, avoiding the
problematic compiler flags.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When adding a C++ file to the build, I forgot to set CXXFLAGS for it,
triggering the error:
android-framebuffer.h:26:21: fatal error: EGL/egl.h: No such file or
directory
I never hit this, because I have EGL headers installed also in my
system, rather than only in $prefix.
Fix this by setting the CXXFLAGS for the android backend.
Reported-by: Scott Moreau <oreaus@gmail.com>
Reported-by: Tiago Vignatti <tiago.vignatti@intel.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The Android backend provides basic EGL/GLES2 graphics, where everything
is always composited. Overlays are not used. Input is stubbed, therefore
there is no input yet.
This adds the first C++ source file into Weston compositor. The Android
gralloc and fb HAL glue code to the Android EGL library is in C++, and
there is no way to access it from plain C. We have a simple wrapper to
the required C++ class API. Android forces the C++ file name extension
to .cpp.
The android backend is compiled by default. However, all Android
specific calls are protected with #ifdef ANDROID, so it will build also
without Android headers. The binary produced without the Android build
system is useless, but allows build-testing generic Weston changes.
Therefore the android backend is not installed.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Here we create a new client/compositor interface in weston to allow
clients to report their x/y cursor position to the compositor. These
values are then used to center the zoom area on this point. This
is useful for everyone, especially people who are visually impaired.
This commit adds a new, built-in screen recorder tool. The tool UI is
still very simple, start with mod-r and stop it again with mod-r.
The recording is written to capture.wcap, in a simple run-length encoded
adhoc format. The wcap-decode tool can be used to extract a single frame
from the capture, for now, but the plan is to hook this up to libvpx and
generate webm output.
Touchpad related code has been rewritten and moved to its own file
accessed by evdev via the dispatch interface.
The various functionality implemented are anti-jitter (don't jumping
around), smoother motions, touch detection, pointer acceleration and
some more.
Pointer acceleration is implemented as one generic part, and one touch
specific part (a profile).
Some ideas and magic numbers comes from xserver and
xf86-input-synaptics.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
By setting an 'evdev_dispatch' struct in 'evdev_input_device' during
device configuration the 'process' function in the associated interface
will be called with received input events. If none is set, a fallback
handler will be set instead that handle generic input functionality.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This is a workaround for platforms, whose EGL headers miss the
definitions for EGL_WL_bind_wayland_display.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>