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>
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
Create a new directory for convenience librariers that can be shared
between compositor components and clients.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
With this the X server directory can become independent from the
installation prefix set by autoconf.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
The shell module is responsible for implementing the higher level
compositor behavior. We default to the desktop-lite shell built in to
the compositor.
For now, we just use glScissor and clip to the extent of the damage region,
but we can do even better by clipping the repaint to the region rectangles.
This shouldn't fail just because someone sets CC=gcc-4.5
explicitly. Besides, this way it also works with compilers
that advertise GCC-compatibility like clang and ICC.
