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>
The Xwayland test has been broken ever since the migration to the
stand-alone Xwayland server binary.
Disable the test, so 'make distcheck' can actually run.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Boyan Ding <stu_dby@126.com>
According to
http://www.gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html
the DISTCHECK_CONFIGURE_FLAGS is for the user, while
AM_DISTCHECK_CONFIGURE_FLAGS is the one to use in Makefile.am.
Make it so.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Boyan Ding <stu_dby@126.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
When running the autogen.sh script, libtoolize complains thusly:
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Silence the warnings by following libtoolize's advice.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This allows for easily testing a compositor's damage tracking in all
currently available configurations including wl_surface.buffer_transform,
wl_surface.buffer_scale, and wl_viewport. It also includes a
--rotating-damage that flag instructs the client to change the
wl_surface.buffer_transform on every commit. This tests the compositor for
proper handling of texture uploads even when the transform has changed but
the buffer size hasn't.
Before in the recursive automake setting, we had tests/logs/ for
explicitly created test log files. There is a Makefile rule to
remove the logs directory on 'make clean'. The rule broke on moving to
non-recursive make, since now we have logs/, not tests/logs/.
Fix the rule to remove the intended directory.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If the test is named xwayland.weston, then the automake test harness
keys it off xwayland.log. Making xwayland.log runs the test.
The test harness has implicit rules to create a %.log from all of
%$TEST_EXTENSIONS. So we have implicit rules to create %.log from %.la
and %.log from %.weston.
We also build xwayland.so, which produces xwayland.la.
When the test harness goes running the xwayland test, it ends up using
the %.la rule, which is wrong. It passes xwayland.la as the test name to
weston-tests-env, which then loads it as a plugin into Weston and waits
for Weston to exit. Which it never does.
Fix this by making the test have a different name than the Xwayland
plugin.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This adds a plugin called screen-share.so. If the screen-share.so module
is imported, it will add the CTRL+ALT+s keybinding to start a screen
sharing session. If you press CTRL+ALT+S, weston will spawn another copy
of weston, this time with the RDP backend, and mirrors the current screen
to it and adds any seats from RDP as aditional seats. The current screen
is defined as the one with the mouse pointer. Currently the CTRL+ALT+s
keybinding is hardcoded as the only way to activate screen sharing. If, at
some point, shells want more control over the screen sharing process, the
API's should be easy to update and export to make this possible.
For security, the command and path to weston is currently hard-coded. It
would not take much aditional code to make this configurable or to allow a
shell to launch other screen-sharing programs. However, handling those
security issues is outside the scope of this patch so it is hard-coded for
now.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This makes simple-shm act like a very simple fullscreen shell client. This
is the kind of interaction one would expect out of a boot splash screen or
similar.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
While disable by default, passing --enable-libinput-backend to
./configure switches the input backend in weston's drm, fbdev and rpi
compositing backends to use libinput instead of udev-seat.c, evdev.c and
friends.
When enabled, weston now also depends on libinput >= 0.1.0.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
For dist tarballs we ship git-version.h but if you do a git archive or
similar to check out a source tree, there's no git-version.h and no
way to make one.
https://bugs.freedesktop.org/show_bug.cgi?id=74459
CC clients/weston-info.o
clients/weston-info.c:31:28: fatal error: wayland-client.h: No such file or directory
compilation terminated.
make[1]: *** [clients/weston-info.o] Error 1
Only triggerable if libwayland is only in a custom prefix.
Fix by adding CLIENT_CFLAGS.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Fix build failures of the kind:
CC tests/bad-buffer-test.o
In file included from tests/weston-test-client-helper.h:28:0,
from tests/bad-buffer-test.c:28:
./protocol/wayland-test-client-protocol.h:35:28: fatal error: wayland-client.h: No such file or directory
compilation terminated.
make[1]: *** [tests/bad-buffer-test.o] Error 1
These are only triggerable if libwayland has not been installed
system-wide, but only in a custom prefix.
Since the Makefile already uses AM_CPPFLAGS, simply add
TEST_CLIENT_CFLAGS to test programs instead of dropping AM_CPPFLAGS.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
