Modify the pkg-config check for setbacklight so that failure only
disables building setbacklight, instead of failing the whole configure.
Signed-off-by: Pekka Paalanen <ppaalanen@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>
This fix xwayland.so that was complaining about jpeg symbols from the
libshared.
Note that xwayland is not using the jpeg ones, but now that symbols are read
up front we need to link anyway.. or break apart that library.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.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.
We had duplicated code in many places, using hardcoded paths for
temporary files into more than one path. Some cases did not bother with
O_CLOEXEC, and all hardcoded paths that might not exist.
Add an OS helper function for creating a unique anonymous file with
close-on-exec semantics. The helper uses $XDG_RUNTIME_DIR as the
directory for a file.
This patch unifies the buffer file creation in both Weston and the
clients.
As simple clients are better not linking to libshared, as it would
require e.g. Cairo, they pull the OS compatibility code directly.
Android does not have mkostemp(), so a configure test is added for it,
and a fallback used if it is not available.
Changes in v2:
remove all the alternate possible directory definitions and use
XDG_RUNTIME_DIR only, and fail is it is not set.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
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>
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>
Some systems may not have execinfo.h. Add a configure test for it, and
if it is not found, make the backtrace() call a no-operation.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
There are no dependencies or requirements there that we don't already
need for weston itself. So lets just always build them.
Use check_PROGRAMS for the matrix unit test case.
weston-launch starts weston and provides mechanism
for weston to set/drop drm master, open a tty,
and read input devices without being root.
Execution is allowed for local-active sessions
or users in the group weston-launch.
mtdev library translates all multitouch based devices to the slotted evdev
protocol. It provides an uniform interface for Weston, which eases mt
implementation when dealing with a big variety of devices.
Weston on drm now directly depends on such library.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
libbacklight is 300 lines of code in one .c file, and we're relying on
udev changes that aren't yet upstream. For now, let's just keep a
copy in weston and if the Xorg DDX drivers start using libbacklight and
it becomes more widely available, we'll make it an external dependency.
DPMS kicks in only when wscreensaver is launched, in the moment that shell
call lock() for the second time. Backlight control internals are managed by
libbacklight:
http://cgit.freedesktop.org/~vignatti/libbacklight/
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
http://lists.freedesktop.org/archives/wayland-devel/2012-January/001975.html
reports a linking problem:
/usr/bin/ld: libtoytoolkit.a(cairo-util.o): undefined reference to
symbol 'png_set_filler@@PNG12_0'
/usr/bin/ld: note: 'png_set_filler@@PNG12_0' is defined in DSO
/usr/lib/i386-linux-gnu/libpng12.so.0 so try adding it to the linker command line
/usr/lib/i386-linux-gnu/libpng12.so.0: could not read symbols: Invalid
operation
collect2: ld returned 1 exit status
make[3]: [weston-terminal] Error 1 (ignored)
A similar problem is diagnosed here:
http://lists.fedoraproject.org/pipermail/devel/2010-March/133601.html
As some distros are shipping linkers, that do not resolve symbols from
implicitly linked libraries, check and link libpng explicitly.
Cc: nerdopolis <bluescreen_avenger@verizon.net>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Do not build toytoolkit applications that use GL, if Cairo-egl is not
available. These applications (which happen to be also the full GL
clients) do not work at all without Cairo-egl, and fail at runtime with
"unable to acquire window surface".
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a new directory tests/ for unit test applications. This directory
will be built only if --enable-tests is given to ./configure.
Add matrix-test application. It excercises especially the
weston_matrix_invert() and weston_matrix_inverse_transform() functions.
It has one test for correctness and precision, and other tests for
measuring the speed of various matrix operations.
For the record, the correctness test prints:
a random matrix:
1.112418e-02 2.628150e+00 8.205844e+02 -1.147526e-04
4.943677e-04 -1.117819e-04 -9.158849e-06 3.678122e-02
7.915063e-03 -3.093254e-04 -4.376583e+02 3.424706e-02
-2.504038e+02 2.481788e+03 -7.545445e+01 1.752909e-03
The matrix multiplied by its inverse, error:
0.000000e+00 -0.000000e+00 -0.000000e+00 -0.000000e+00
0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
-0.000000e+00 -0.000000e+00 0.000000e+00 -0.000000e+00
0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
max abs error: 0, original determinant 11595.2
Running a test loop for 10 seconds...
test fail, det: -0.00464805, error sup: inf
test fail, det: -0.0424053, error sup: 1.30787e-06
test fail, det: 5.15191, error sup: 1.15956e-06
tests: 6791767 ok, 1 not invertible but ok, 3 failed.
Total: 6791771 iterations.
These results are expected with the current precision thresholds in
src/matrix.c and tests/matrix-test.c. The random number generator is
seeded with a constant, so the random numbers should be the same on
every run. Machine speed and scheduling affect how many iterations are
run.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
