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 request simulates device creation/destruction from evdev (libinput)
v2: added support for touch. Touch is not supported yet,
but better be prepared
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This rewrites basically all of the text inside xdg-shell to be up to
date, clearer, and rid of wl_shell and X11 terminology.
[jadahl: Added paragraph about popup surface mapping order.]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Send an invalid_parent error when the client tries to create a popup
with a paren that is neither a xdg_surface nor a xdg_popup.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Either in destroy or get_xdg_popup.
[jadahl: Verify that the new popup is the top most when mapping instead
of creating. Some renaming.]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
There haven't been any ideas for flags, so we don't need a useless,
unused parameter hanging around. Any future ideas should be done with a
new request entirely.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It doesn't serve any purpose, as it's a serial that the client gave to
the server when starting the popup, which the client already has.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
Add the missing feedback flags to the Presentation extension protocol
specification.
These flags are slightly different from the previous RFCv3.1 definition:
http://lists.freedesktop.org/archives/wayland-devel/2014-March/013598.html
Now, all compositors are safe to use 0 as the flags if they don't bother
setting them properly. 0 is the "worst case" with the least guarantees.
The meaning of ZERO_COPY is not exactly the opposite of the old COPY
flag. ZERO_COPY is more strict, but applies only to that one surface.
Therefore it can be used to verify a zero-copy video playback pipeline,
also to a hardware overlay.
There is no longer a flag to clearly indicate if the final presentation
was done by a copy or a page flip. ZERO_COPY forbids the copy, but VSYNC
alone does allow copy in case it cannot tear. It is possible to have
first a compositing pass, and then another copy into the frontbuffer,
and still set VSYNC if it cannot tear. Usually "cannot tear" is too
hard to guarantee with a copy, so it often implies a page flip.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
- 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>
- 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>
Needed for properly reporting role violations from
xdg_shell.get_xdg_surface and .get_xdg_popup.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.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>
Obvious this affects the source, not destination.
Reported-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The experimental versioning has not been updated when it was supposed
to. Let's try to be better at it now, as xdg-shell is close to have its
first stable version.
Bump the version now to bring the world into the same exact version.
There may be some protocol changes still coming, but we try to land them
before 1.6 gets out. Those changes will bump the experimental version
again as needed.
When 1.6.0 is released, the experimental version will no longer be
bumped, and no incompatible protocol changes will be made. Xdg-shell.xml
file will move to Wayland in 1.7.0, drop the experimental versioning,
and become stable.
Cc: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Panels are always assumed to be on the top edge of the output. If this
is not the case views will be placed under the panel, wherever it is,
and maximize doesn't use the correct space allocated for views.
By telling the server on which edge the panel is located, it can
correctly calculate where to put new views and how big maximized views
should be.
[Pekka Paalanen: the user of this protocol so far is Maynard.]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Currently, there is a fun flicker when toggling maximization or
fullscreen on a window in mutter or more sophisicated compositors
and WMs.
What happens is that the client want so go maximized, so we
calculate the size that we want the window to resize to (640x480),
and then add on its margins to find the buffer size (+10 = 660x500),
and then send out a configure event for that size. The client
renders to that size, realizes that it's maximized, and then
says "oh hey, my margins are actually 0 now!", and so the compositor
has to send out another configure event.
In order to fix this, make the the configure request correspond to
the window geometry we'd like the window to be at. At the same time,
replace set_margin with set_window_geometry, where we specify a rect
rather than a border around the window.
Currently, there's a race condition. When resizing from the left, and
a client attaches a buffer after the resize ends, you suddenly see the
buffer jump to the right, because the resize ended while multiple
attaches were in-flight. Making resize a state can fix this, as the
server can now know exactly when the resize ended, and whether a commit
was before or after that place.
We don't implement the correct tracking in this commit; that's left as
an exercise to the reader.
Additionally, clients like terminals might want to display resize popups
to display the number of cells when in a resize. They can use the hint
here to figure out whether they are resizing.
The states system, so far, has been a complicated mix of weird APIs
that solved a real race condition, but have been particularly ugly
for both compositors and clients to implement.
It's a confusing name that comes from the ICCCM. The ICCCM is best
forgotten about.
With the addition of the potential new "transient" role meaning a
parent-relative toplevel like a long-lived popup, used for e.g.
tooltips, the set_transient_for name will become even more confusing.
There was a bug in wayland-scanner that failed to detect when an
message with implicitly set version (i.e. version 1) came after a
message with a newer version. This patch fixes the weston desktop shell
protocol to pass again.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Let's make the source and destination size rules consistent: neither can
have zero, {-1, -1} disables it, and other negatives are not allowed.
The sanity of allowing zero sized source rectangle as debatable. Now the
minimum becomes 1/256x1/256, and with output_scale the actual samples
may be even smaller. That should be enough.
On not allowed values, raise a protocol error. This should help catch
bugs in clients that accidentally send garbage values.
The old wl_viewport.set request remains the same, and can still produce
zero sized source rectangle.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
'close' is more consistent with the purpose of the event than
'delete', and it is also c++ friendly, since 'delete' is a keyword.
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Bump wl_scaler and wl_viewport versions to 2. Add new requests
wl_viewport.set_source and .set_destination, which are meant to replace
wl_viewport.set request.
Now a client can set and unset just one of source rectangle and
destination size. Define the semantics when one of these is unset.
Implement these semantics changes in compositor and pixman renderer.
GL-renderer does not need changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Rather than require that the client implement two methods for every state,
simply have one global request, change_state, and one global event,
request_change_state.
Use a static assert to catch mismatch between implementation and
interface version. Fix window.c to not use XDG_SHELL_VERSION_CURRENT,
which will fail to catch version mismatches. The implementation version
must updated manually when the implementation is updated to use the new
interface.
Responsivenes is a per-client thing so we move the ping/pong functionality
to xdg_shell. Having this per-window was carries over from the EWMH
protocol, where the WM has no other way to do this. In wayland, the
compositor can directly ping the client that owns the surface.
This is used to figure out the size of "invisible" decorations, which we'll
use to better know the visible extents of the surface, which we can use for
constraining, titlebars, and more.
This is equivalent to WM_DELETE_WINDOW request under X11, or equivalent
to pressing the "close" button under CSD. Weston currently doesn't have
a compositor-side way to close the window, so no new code is needed on
its side.
This seems like a better name, and will not conflict if someone later
extends wl_surface with a request scaler_set (yeah, unlikely).
This code was written by Jonny Lamb, I just diffed his branches and made
a patch for Weston.
Cc: Jonny Lamb <jonny.lamb@collabora.co.uk>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Pekka Paalanen
Marek Chalupa
Bryce Harrington
Jasper St. Pierre
Jonas Ådahl
Derek Foreman
Nobuhiko Tanibata
Seedo Eldho Paul
Jonny Lamb
Boyan Ding
Bryce W. Harrington
Kristian Høgsberg
Jason Ekstrand
Giulio Camuffo