Commit a7592019 introduced an optimization that caused some
exposay struct members to not be properly initialized, particularly
cur_output, leading to crashes in some circumstances (e.g. pressing
the down arrow key after going to exposay).
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Both weston_move_scale_run() and weston_slide_run() were broken in
commit 3a869019. Commit a4a6f161 fixed and explained the problem for
weston_slide_run() but weston_move_scale_run() remained broken.
To fix weston_move_scale_run(), weston_view_animation_run() is also
required. It was removed when _run() was split into two functions
_create() and _run() in commit f5cc2b56, but _run() was not added in
this commit.
This is to avoid recursing into weston_compositor_build_view_list()
and therefore fix crashing when destroying a stack of visible subsurfaces
due to weston_compositor_build_view_list() being called recursively
and corrupting the lists it works on.
https://bugs.freedesktop.org/show_bug.cgi?id=79684
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.
Also update configure.ac to require libinput 0.3 when enabled, as it is
the version where double replaced li_fixed_t.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Post release bump. The master branch version is always x.y.90,
where x.y is the most recent stable branch. This lets other packages
rely on git master as opposed to 1.5.0.
wl_list_for_each dereference's output to increment the
next iteration of the loop. However, output is free'd
inside the loop resulting in a dereference to free'd
memory.
Use wl_list_for_each_safe instead, which is designed to
handle this kind of pattern.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Once we've updated the window state and scheduled a resize, we know that
the next frame we send to the compositor will match the configured state.
This means we can just ack the configure immediately and not jump
through hoops to try to do it from the redraw stage.
As the protocol says, the states determine how the width and height
arguments should be interpreted, so it makes logical sense to do the
interpretation after.
With most of the code in send_configure_for_surface, the helper
methods don't give us that much benefit, so stop using them. We
can't kill them off, as they're part of the shell interface and
used by the WM.
Currently, there's a giant bug in how xdg-shell state management
is done. If a client calls set_fullscreen and then set_maximized,
it will get two configure events:
=> set_fullscreen
<= configure(800, 600, [STATE_FULLSCREEN])
=> set_maximized
<= configure(800, 560, [STATE_FULLSCREEN, STATE_MAXIMIZED])
Since fullscreen takes precedence over maximized, the client will
render full-screen at 800x600 first, and then 800x560 next. As
a result, the surface gets the wrong size.
This is because the code that sends out configure requests is
"immediate" -- when an app calls set_maximized, we immediately
send out the configure event that would have happened if we
transitioned immediately into maximized mode.
In wl_shell, this is correct behavior. However, in xdg-shell,
this is wrong. State needs to be more carefully managed in
xdg-shell, as states aren't exclusive.
Pull all the code that sends out configure events out and send
them centrally, based on Weston's on surface state management.
This should work with both wl_shell and xdg_shell's strategies.
Add a new state_changed_handler callback to the window to know when the
window has changed state; the terminal will use this to know when the
window started and ended its resize operation, and modify the terminal's
titlebar accordingly.
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.
xdg-shell mandates that the FULLSCREEN state means that we must match
the size that we were configured to, at least by default. Other states
or protocol extensions might relax this requirement, but at least for
now implement the behavior specified in the protocol documentation.
Toytoolkit was not designed to handle input from subsurfaces and
instead it expects subsurfaces to have an empty input region. That way
input events for subsurfaces are generated on the main surface and
there is no need to convert coordinates before reporting the event to
the user.
However it is possible that a subsurface has a non-empty input region,
but in that case those events aren't properly processed. The function
window_find_widget() assumes the coordinates are in the main surface
coordinate space, and ends up chosing the wrong widget.
This patch changes the input code to completely ignore input events from
subsurfaces. This option was chosen instead of ensuring that the input
region on those surfaces is always empty since there's no enforcement
that a subsurface should completely overlap with the main surface. If
an event happens in the area of the surface that doesn't overlap, the
event could cause a completely unrelated surface to be picked.
https://bugs.freedesktop.org/show_bug.cgi?id=78207
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>
[paalanen: added also *.trs to ignore]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
The calculation off the vertical offset between the widget coordinates
and where the text was rendered was wrong. It was using the constant for
horizontal offset for that too.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=78411
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>
Again, load the shell plugin with full path, rather than possibly find an
old version from a previous installation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If we do not specify the full path to xwayland.so, Weston can find an
old one installed in a $prefix and use that instead of the freshly built
one.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Use --no-config to avoid loading arbitrary weston.ini files from unit
tests. It may affect the unit test results.
I actually hit the following case:
[13:34:04.636] Using config file '/home/pq/local/etc/weston.ini'
[13:34:04.636] Loading module '/home/pq/git/weston/.libs/headless-backend.so'
[13:34:04.637] launching '/home/pq/local/libexec/weston-keyboard'
[13:34:04.644] Loading module '/home/pq/local/lib/weston/desktop-shell.so'
[13:34:04.644] Loading module '/home/pq/local/lib/weston/xwayland.so'
[13:34:04.648] unlinking stale lock file /tmp/.X1-lock
[13:34:04.648] xserver listening on display :1
[13:34:04.648] Loading module '/home/pq/git/weston/.libs/./xwayland.so'
[13:34:04.648] xserver listening on display :2
[13:34:04.648] Module '/home/pq/local/lib/weston/xwayland.so' already loaded
Weston tries to load xwayland module three times, or which twice it
succeeds. This might not make the xwayland test end well. Or at all,
actually.
Adding --no-config should remove one of these loads of xwayland.so.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Useful for unit tests. If Weston finds a weston.ini during unit tests,
it will load it and all the modules it asks for. We need a way to
prevent loading arbitrary modules from the command line.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Only accept specific literal values from the environment variable
WESTON_LIBINPUT_LOG_PRIORITY... "debug", "info", or "error".
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
The error handling for the function that writes the encoded frame on
the disk was bogus, always assuming the buffer supplied to the encoder
was too small. That would cause a bigger buffer to be allocated and
another attempt to encode the frame was done. In the case of a failure
to write to disk (due to ENOSPC, for instance) that would cause an
endless loop.
Possibly-related-to: https://bugs.freedesktop.org/show_bug.cgi?id=69330
Filter sampling outside the source image can leak black into the edges
of the
desktop image. This is most easily seen by scaling the default tiled image
with this weston.ini:
# no background-image and no background-color
background-type=scale-crop
The check to avoid calling weston_keyboard_set_focus() for a seat that
didn't have a keyboard in restore_focus_state() was cheking the wrong
seat (the one from the previous loop). That caused a crash when
switching workspaces if there was an extra seat that didn't have a
keyboard.
https://bugs.freedesktop.org/show_bug.cgi?id=78349
If simple-touch ran on a compositor with multiple seats, and the first
one happened to have the touch capability while the second one didn't,
the handler for seat capabilities would destroy the wl_touch device it
created on the first call for the first seat when it was called a again
for the second seat that has not touch capabilities.
Fix this problem by creating a separate struct for each seat.
https://bugs.freedesktop.org/show_bug.cgi?id=78365
Views that extend past the bottom of the output are still visible after
the workspace animation ends but before its layer is hidden. When the
layer was hidden, nothing would cause those regions to be repainted,
leading to artifacts.
https://bugs.freedesktop.org/show_bug.cgi?id=78363
Quells warning:
clients/keyboard.c: In function ‘keyboard_handle_key.isra.5’:
clients/keyboard.c:556:11: warning: ‘label’ may be used uninitialized in
this function [-Wuninitialized]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
