AM_CFLAGS is the default for any target that doesn't specify its
own cflags. We should use AM_CFLAGS in preference to GCC_CFLAGS
so we can change AM_CFLAGS and get all targets.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
[pekka: fixed patch conflicts]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This removes the weston-screensaver client.
Screensavers are not so useful, DPMS is much better. This example has
existed here for a good while, and things that we could learn from it
have been learnt.
Nowadays this is just dead weigth, which is usually not even compiled,
because it depends on both cairo-gl and GLU. Removing it removes the
only possible dependency to GLU and one user of cairo-gl. Now the last
user of cairo-gl is gears (clients/nested.c uses cairo-glesv2).
Support for screensavers is still left in desktop-shell, so external
projects can still have their screensavers if they want.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
We don't want to use installed binaries when running tests.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
To help reduce code duplication and also 'kitchen-sink' includes
the ARRAY_LENGTH macro was moved to a stand-alone file and
referenced from the sources consuming it. Other macros will be
added in subsequent passes.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Add the output screenshot to CLEANFILES so it's properly removed on
distclean, and add the reference files and ini to EXTRA_DIST so
distcheck can find them.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Tested-by: Bryce Harrington <bryce@osg.samsung.com>
This also serves as a proof of concept of the screen capture
functionality and as a demo for snapshot-based rendering verification.
Implements screenshot saving clientside in the test itself.
This also demonstrates use of test-specific configuration files, in this
case to disable fadein animations and background images.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Implements a simple mechanism to allow tests to customize the
configuration. For a given <name>-test.c just place a <name>.ini file
at the same location as the test itself. Alternately, you can generate
a <name>.ini in the same directory that the compiled test is placed
(i.e. the top builddir). If no configuration file is found, then no
configuration will be used (i.e. --no-config is specified.)
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
At least in some shells test needs 3 arguments for string comparison
if test $foo=yes ...
will always be true.
if test $foo = yes ...
will perform a string comparison.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-By: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Added build error message when 'make install' is run as non-root
and the --disable-setuid-install configuration option has not been
used.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This is the ivi_layout stand-alone test controller module that does not
require any clients to run. Therefore it is much simpler than
ivi_layout-test-plugin.c and does not need a matching part in
ivi_layout-test.c.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Testing the ivi_layout API requires two things:
- the tests must be written as a controller module to access the API
- the tests need a helper client to create some objects that can then be
managed via the API
This patch adds all the infrastructure and two different kinds of
example tests.
Internal ivi-shell (ivi_layout) API tests are listed as ivi-*.la files
in TESTS in Makefile.am. Weston-tests-env detects these, and runs Weston
with ivi-shell, and loads the given module as a controller module, not
as a normal plugin.
The test controller module ivi-*.la will launch a helper client. For
ivi-layout-test.la the helper client is ivi-layout.ivi.
The helper client uses the weston-test-runner framework to fork and exec
each TEST with a fresh connection to the compositor.
The actual test is triggered by the weston_test_runner protocol
interface, a new addition to weston-test.xml. The helper client uses
weston_test_runner to trigger a test, and the server side of the
interface is implemented by the test controller module
(ivi-layout-test.la).
The server side of weston_test_runner uses the same trick as
weston-test-runner.h to gather a list of defined tests. A test is
defined with the RUNNER_TEST macro.
If a test defined by RUNNER_TEST succeeds, an event is sent to the
helper client that it can continue (or exit). If a test fails, a fatal
protocol error is sent to the helper client.
Once the helper client has iterated over all of its tests, it signals
the batch success/failure via process exit code. That is cought in the
test controller module, and forwarded as Weston's exit code.
In summary: each ivi_layout test is a combination of a client side
helper/setup and server side actual tests.
v2: Load weston-test.so, because create_client() needs it.
v3: add a comment about IVI_TEST_SURFACE_ID_BASE.
v4: Rebased to upstream weston-tests-env changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com> (v2)
This simply tests that Weston starts with ivi-shell, and ivi_application
is present.
Changes in v3:
- Rebased to upstream weston-tests-env changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com> (v2)
If you do an out-of-tree build, all the images will be left in the
srcdir. Fix their paths.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
The ivi-shell / hmi-controller cannot run without a properly populated
config file. Generate a config file especially for tests, which includes
paths to the build dirs.
The generated file will be used by following patches adding ivi-shell
tests.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Test misc races when adding/releasing devices
v2.: use one roundtrip after releasing devices
add touch support
v3.: remove useless checks
add few comments
repeat tests 30 times instead of 100 times
(it took too long, 30 is enough)
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add a new Weston plugin under tests/ for manual testing of the
surface-shooting API.
The debug key binding 'h' triggers a surface shot from the surface that
currently has the pointer focus. The shot is written in PAM format into
a file. PAM format was chosen because it is dead-simple to write from
scratch and can carry an RGBA format.
Changes in v2:
- check fprintf calls, fix a malloc without free
- remove stride and format arguments from the API
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Daniel Stone <daniels@collabora.com>
For easy creation of unique new files. I'm looking at you,
screenshooter.
This code is based on timeline.c weston_timeline_do_open().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Daniel Stone <daniels@collabora.com>
wayland-test isn't and will never be wayland protocol, it's weston internal.
Renamed wayland-test to weston-test, and wl_test to weston_test.
Also added a Big Fat Warning to the description of weston_test to try to
keep people from thinking it's a good idea to use some of these functions
outside of testing.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Some of the .png files are specific to ivi-shell. Avoid installing
them to "$prefix/share/weston" if ivi-shell has explicitly been
disabled at configure time.
Signed-off-by: Manuel Bachmann <manuel.bachmann@open.eurogiciel.org>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If Xwayland is not in /usr/bin, distcheck will fail without patch
023b265b, which propagates @XSERVER_PATH@ to distcheck but blocks other
use of the DISTCHECK_CONFIGURE_FLAGS env var. Instead, revert the fix
and merely document the need for setting DISTCHECK_CONFIGURE_FLAGS
manually.
Revert "build: Pass along any user-specified xserver path to distcheck"
This reverts commit 023b265b44.
The replacement xwayland-test should succeed, so we should run it
from distcheck again.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
dist_wayland_session_DATA is not set anywhere before, so using +=
results in:
error: dist_wayland_session_DATA must be set with '=' before using '+='
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
So that we can test the per-surface ZERO_COPY flag:
- start Weston on DRM backend
- run ./weston-simple-egl -o (need to be opaque to end up on overlay)
- hit debug key 'V' to enable the (broken) hw overlays
The debug key is used by first hitting Mod+Shift+space, then hitting 'v'.
Enabling overlays should change the flags from 0x7 to 0xe. To verify the
window is really on an overlay, use debug key 'S' to tint all
GL-composited things green.
This patch is not intended for upstream.
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
ivi-layout.so is separately built and loaded by using dlopen with
RTLD_GLOBAL. This was because these apis defined in ivi-layout.so shall
be used by ivi-modules; e.g. hmi-controller. This shall be improved that
a struct ivi_layout_api contains the whole exported API as function
pointers to be exposed as module_init.
This patch alone builds, but loading controller modules at runtime
failes. This failure will be fixed by following patches.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Logging is activated and deactivated with the debug key binding 't'.
When activated, it creates a new log file, where it records the events.
The log file contains events and detailed object information entries in
JSON format, and is meant to be parsed in sequence from beginning to the
end.
The emitted events are mostly related to the output repaint cycle, like
when repaint begins, is submitted to GPU, and when it completes on a
vblank. This is recorded per-output. Also some per-surface events are
recorded, including when surface damage is flushed.
To reduce the log size, events refer to objects like outputs and
surfaces by id numbers. Detailed object information is emitted only as
needed: on the first object occurrence, and afterwards only if
weston_timeline_object::force_refresh asks for it.
The detailed information for surfaces includes the string returned by
weston_surface::get_label. Therefore it is important to set
weston_timeline_object::force_refresh = 1 whenever the string would
change, so that the new details get recorded.
A rudimentary parser and SVG generator can be found at:
https://github.com/ppaalanen/wesgr
The timeline logs can answer questions including:
- How does the compositor repaint cycle work timing-wise?
- When was the vblank deadline missed?
- What is the latency from surface commit to showing the new content on
screen?
- How long does it take to process the scenegraph?
v2: weston_surface::get_description renamed to get_label.
v3: reafctor a bit into fprint_quoted_string().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- introduces ivi-shell/input-panel-ivi.c which is basically copied
from desktop shell. It shall be improvaded to remove duplicate
implementation.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- introduces reference images used by weston-ivi-shell-user-interface.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- introduces ivi-shell-user-interface.c
This is launched from hmi-controller by launch_hmi_client_process and
invoke a
client process.
The basic flow is as followed,
1/ process invoked
2/ read configuration from weston.ini.
3/ draw png file to surface according to configuration of weston.ini
4/ all parts of UI are ready. request "UI_ready" to draw UI.
5/ Enter event loop
6/ If a surface receives touch/pointer event, followings are invoked
according
to type of event and surface
6-1/ If a surface to launch ivi_application receive touch up, it execs
ivi-application configured in weston.ini.
6-2/ If a surface to switch layout mode receive touch up, it sends a
request,
ivi_hmi_controller_switch_mode, to hmi-controller.
6-3/ If a surface to show workspace having launchers, it sends a
request,
ivi_hmi_controller_home, to hmi-controller.
6-4/ If touch down events happens in workspace,
ivi_hmi_controller_workspace_control is sent to slide workspace.
When control finished, event:
ivi_hmi_controller_workspace_end_control
is received.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- hmi-controller.so
- introduces hmi-controller.so
The library is used to manage layout of surfaces/layers. Layout change
is triggered by ivi-hmi-controller protocol, ivi-hmi-controller.xml. A
reference how to use the protocol, see ivi-shell-user-interface.c.
In-Vehicle Infotainment system usually manages properties of
surfaces/layers by only a central component which decide where
surfaces/layers shall be. This is differenct use case from desktop
style; each application can request property of its window via xdg-shell
protocol, like fullscreen and set its to top level. In-Vehicle
Infortainment system doesn't allow each application to chagen them from
its application because of safty reasons. The concept of layer is
simillar with a use case of cursor layer of Destop. For In-Vehicle
Infortainment system, it is extended to all applications. For example,
rearview camera application is assigned to a layer to group several
surfaces, e.g. captured image and drawing lines separately. Central
manaegr can control property of the layer of rearview camera.
This reference show examples to implement the central component as a
module of weston.
Default Scene graph of UI is defined in hmi_controller_create. It
consists of
- In the bottom, a base layer to group surfaces of background, panel,
and buttons
- Next, a application layer to show application surfaces.
- Workspace background layer to show a surface of background image.
- Workspace layer to show launcher to launch application with icons.
Paths to binary and icon are defined in weston.ini. The width of
this layer is longer than the size of screen because a workspace
has several pages and is controlled by motion of input.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- introduces ivi-hmi-controller.xml
This protocol realizes following features,
- UI ready
- changing modes; tiling, side by side, full_screen, and random
- Give control a surface; workspace to be controlled by using ivi layout
APIs
- Display/undisplay a surface; home contains sevaral workspaces to
launch applications
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- ivi-shell.so
- introduces ivi-shell/ivi-shell.[ch]
In-Vehicle Infotainment system traditionally manages surfaces with
global identification. A protocol, ivi_application, supports such a
feature by implementing a request, ivi_application::surface_creation
defined in ivi_application.xml.
The ivi-shell explicitly loads ivi-layout.so and a module to add
business logic like how to layout surfaces by using ivi-layout APIs.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- ivi-layout.so
- introduces ivi-layout-export.h, ivi-layout.[ch]
API set of controlling properties of surface and layer which groups
surfaces. An unique ID whose type is integer is required to create
surface and layer. With the unique ID, surface and layer are identified
to control them. The API set consists of APIs to control properties of
surface and layers about followings,
- visibility.
- opacity.
- clipping (x,y,width,height).
- position and size of it to be displayed.
- orientation per 90 degree.
- add or remove surfaces to a layer.
- order of surfaces/layers in layer/screen to be displayed.
- commit to apply property changes.
- notifications of property change.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- introduces ivi-application.xml
Many applications in an IVI-system are special single-purpose
applications that have a very specific role in the whole IVI UI, for
example a rear camera, speedometer, map, etc. The IVI system vendor
specifies what these are and how they integrate into the UI. They also
vary between particular IVI systems. This is why we use (system-)global,
unique, pre-determined ID numbers to tell what wl_surface is which
application, instead of writing specific shell requests for each one.
Using ID numbers allows vendors to easily invent new component
applications without extending or breaking the actual Wayland protocol.
In IVI-systems, the ID is a standard concept already used in several
APIs, with a vendor-specified global definition of ID assignments.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This fixes this build failure:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/bin/ld:
clients/weston_multi_resource-multi-resource.o: undefined reference to
symbol 'clock_gettime@@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/bin/ld:
note: 'clock_gettime@@GLIBC_2.2.5' is defined in DSO /lib64/librt.so.1
so try adding it to the linker command line
/lib64/librt.so.1: could not read symbols: Invalid operation
Add tests for triggering the role conflict when a wl_surface is already
a wl_shell_surface and then attempted to be made into a sub-surface, and
vice versa.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This started as a copy of simple-shm.c before it was converted to
xdg_shell.
This demo excercises the presentation feedback interface in five
different modes:
- A continuous repaint loop triggered by frame callbacks, and using
immediate commits, just gathering presentation feedback and computing
some time intervals for statistics.
- The same as above, except with 1s sleep before actually repainting as
a response to frame callback. This tests how well the compositor can
do a repaint from idle state (not continuously repainting), assuming
nothing else is causing repaints.
- A continuous repaint loop triggered by 'presented' events rather than
by frame callbacks. If Weston uses an appropriate scheduling
algorithm, this mode achieves the smallest possible frame latency
(below one output refresh period).
In all modes, all frames are pre-rendered at startup, so no rendering
happens during the animation.
[Louis-Francis Ratté-Boulianne: split queuing feature]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Add accurate presentation timing features to Wayland: queueing and
feedback.
This specification is based on the draft written by Frederic Plourde
<frederic.plourde@collabora.co.uk> and redesigned by Pekka Paalanen.
The RFC v2 version is from
http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html
Changes in v3:
* associate presentation time to current surface contents
This implements the suggestion from
http://lists.freedesktop.org/archives/wayland-devel/2014-February/013066.html
which prevents surface content from jumping backwards in time if a
client retroactively queues an update with a target time in the past.
* use 64-bit tv_sec in presentation
The time_t type used in struct timespec could be almost anything. POSIX
probably defines it to be an integer, but not the size. Apparently it is
usually 'long', which makes it 64-bit on x86_64.
To be able to fully represent timespec values returned by clock_gettime,
change the protocol to use 64 bits for the tv_sec part.
* define an error for invalid tv_nsec
This allow us to rely on the normalized timestamp form.
* define some interactions with sub-surfaces
Sub-surface cached state updates (synchronized mode) are designed
especially for resizing. As queued updates are not meant to produce any
resizing-like effects, they also do not trigger any sub-surface
operations.
* add sub-headings as xml comments
* queued update cannot map
Because before mapping, the surface has no main output assigned. An
immediate commit is needed anyway, to be able to set all the surface
state, which a queued update cannot touch.
* frame callbacks are not queued
It is not known when queueing frame callbacks would be useful.
Changes in v4:
* remove mentions of the queuing feature
The specification has been split and the queuing feature will be added
back in another version of the extension.
* add flags argument to 'presented' event
Describe the nature of how the update was presented to screen and the
characteristics of the feedback information. No flags have been
defined for now.
* add a protocol error code for invalid flags
Changes in v5:
* remove the destroy method for the feedback object
The protocol object should instead be automatically destroyed after
a 'presented' or 'discarded' event has been triggered.
* some grammatical corrections to the specification
[Louis-Francis Ratté-Boulianne: split the spec in two parts]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
v3 Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Derek Foreman
Pekka Paalanen
Jon A. Cruz
Bryce Harrington
Marek Chalupa
Jonny Lamb
Manuel Bachmann
Lubomir Rintel
Nobuhiko Tanibata
Peter Hutterer
Javier Jardón