There is more state than just the application window width and height that
affects whether calling weston_wm_window_configure() is necessary: everything
that affects the frame window, fullscreen state in particular. Therefore do not
skip the call by just width and height.
If send_configure() happens to be called "unnecessarily", this will now forward
some of those calls to the X11 clients. However, since it uses an idle task, it
should not result in a flood at least. And if send_configure() is spammed,
maybe that should then be fixed in its callers.
This patch should fix the misplacement of a fullscreen X11 window due to the
frame window being incorrectly sized and positioned, and the app window
incorrectly positioned inside the frame window.
The fullscreen window problems were observed in a case where the window does
not hit legacy_fullscreen() but first maps and then sets
_NET_WM_STATE_FULLSCREEN. Additionally the initial window size must match the
output size where it gets fullscreened. In that case the frame window was left
as if not fullscreened.
This practically reverts 3f53d9179b. I'm not sure
what problem that patch was fixing, but I couldn't make any resizing freeze.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Spotted this in debug log:
[xwm-wm-x11] XWM: configure window 4194324: x=32 y=32 width=1920 height=1080 border_width=0 stack_mode=0
[xwm-wm-x11] XWM: configure window 0: width=1984 height=1144
Trying to configure window 0 makes no sense. So do not try.
To avoid patching two different places with the same thing, refactor the code
into a common helper.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It would lead to use-after-free if there was a pending idle callback to
weston_wm_window_configure() when the weston_wm_window gets destroyed. Make
sure the callback will not fire.
Found by inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This function is called also directly from weston_wm_window_set_toplevel(). If
configure_source is set at that point, simply resetting the pointer will "leak"
the source until it fires and calls this function again.
Let's keep the variable up-to-date by removing the source when called,
dispatched or not. This removes the second call. I only hope it doesn't cause
issues. This is also necessary if we intend to remove the source on window
destruction too.
Found by inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It looks like commit ad0da4596d introduced a bug
for X11 windows that are initially fullscreen by adding code to the end of
xserver_map_shell_surface() while ignoring the 'return' that this patch
removes. That may have caused some annoying window state issues, but the
problem became more pronounced with 7ace831ca6
when used with an Xwayland version that honours _XWAYLAND_ALLOW_COMMITS.
In the latter case, there is a possiblity the window will never show up, as XWM
forgets to set allow_commits=true. However, the window may sometimes actually
show up due to an oversight in Xwayland: the Present code may be flipping the
window buffers and not checking _XWAYLAND_ALLOW_COMMITS if it is supposed
commit at all.
Since then, f568968f8a added more places where
allow_commits is set to true, masking the window-does-not-show-up issue. Window
pending state likely still remained an issue.
This patch properly fixes the "window never appears" issue by making sure
allow_commit=true is set. At the same time, it ensures the pending state
functions are called at the end of xserver_map_shell_surface(), which may fix
some window state issues like misplaced decorations and/or position of
initially-fullscreen windows. Unfortunately, it certainly does not fix all such
state problems.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Fixes missing prototypes compilation warnings emitted when a function
is defined before its prototype is declared.
These warnings were introduced over time since the switch to meson
because the -Wmissing-protoypes was not included in the compilation
arguments.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
There's a function named weston_compositor_log_scope_destroy()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_scope_destroy(), as the argument is a
struct weston_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.
Also, bump libweston_major to 9.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The mask argument is uint16_t so declare the variable with the same.
Suggested-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Knowing the kind of decoration drawn will help track down issues with
unexpected decorations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Print the changes to the debug scope, helping to figure out why Xwayland is or
is not committing.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add the missing newline to printing a property that is of type cardinal array.
Fixes messed up debug scope output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Initially, `_XWAYLAND_ALLOW_COMMITS` was introduced in commit 7ace831ca
to avoid drawing the window content before it's ready to be shown.
But a repaint might also be triggered by the client damages before the
XWM has finished drawing its window decorations and drop shadows, which
previously was not too much of an issue since the XWM could still
finish updating the X11 window after the buffer was submitted.
However, with the addition of multiple window buffers in Xwayland [1]
which are aimed at preventing the X11 clients from updating the buffer
after it's been committed, this is no longer possible.
As a result, the use of multiple window buffers in Xwayland can cause
ugly repainting effects of the decorations if the buffer is submitted
before the XWM has finished painting its decorations.
Use the X11 property `_XWAYLAND_ALLOW_COMMITS` can be used to avoid
this, by controlling when Xwayland should commit changes to the Wayland
surface.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This introduces a new convention of checking through the compositor destroy
listener if the plugin is already initialized. If the plugin is already
initialized, then the plugin entry function succeeds as a no-op. This makes it
safe to load the same plugin multiple times in a running compositor.
Currently module loading functions return failure if a plugin is already
loaded, but that will change in the future. Therefore we need this other method
of ensuring we do not double-initialize a plugin which would lead to list
corruptions the very least.
All plugins are converted to use the new helper, except:
- those that do not have a destroy listener already, and
- hmi-controller which does the same open-coded as the common code pattern
did not fit there.
Plugins should always have a compositor destroy listener registered since they
very least allocate a struct to hold their data. Hence omissions are
highlighted in code.
Backends do not need this because weston_compositor_load_backend() already
protects against double-init. GL-renderer does not export a standard module
init function so cannot be initialized the usual way and therefore is not
vulnerable to double-init.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We have two kinds of libweston users: internal and external. Weston, the
frontend, counts as an external user, and should not have access to libweston
private headers. The shell plugins are external users as well, because we
intend people to be able to write them. Renderers, backends, and some plugins
are internal users who will need access to private headers.
Create two different Meson dependency objects, one for each kind.
This makes it less likely to accidentally use a private header.
Screen-share is a Weston plugin and therefore counts as an external user, but
it needs the backend API to deliver input. Until we are comfortable exposing
public API for that purpose, let it use internal headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As 'new_subscription' can create additional objects, 'destroy_subscription'
will be needed when cleaning up.
As this requires a libweston_major bump (noticed by @pq), bump it up to
8.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
The xwayland plugin (XWM) is a libweston plugin, so it has no business using
Weston things. Luckily its not, this was just a left-over include. Remove it to
reduce confusion.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Define common_inc which includes both public_inc and the project root directory.
The project root directory will allow access to config.h and all the shared/
headers.
Replacing all custom '.', '..', '../..', '../shared' etc. include paths with
common_inc reduces clutter in the target definitions and enforces the common
#include directive style, as e.g. including shared/ headers without the
subdirectory name no longer works.
Unfortunately this does not prevent one from using private libweston headers
with the usual include pattern for public headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When all shared/ headers are included in the same way, we can drop unnecessary
include seach paths from the compiler.
This include style was chosen because it is prevalent in the code base. Doing
anything different would have been a bigger patch.
This also means that we need to keep the project root directory in the include
search path, which means that one could accidentally include private headers
with
#include "libweston/dbus.h"
or even
#include <libweston/dbus.h>
IMO such problem is smaller than the churn caused by any of the alternatives,
and we should be able to catch those in review. We might even be able to catch
those with grep in CI if necessary.
The "bad" include style was found with:
$ for h in shared/*.h; do git grep -F $(basename $h); done | grep -vF '"shared/'
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Turns out dnd.c does not actually need cairo-util.h. This was found when
unifying the include directives of all shared/ headers. Removing this makes one
less place to fix.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As we transition towards a more generic API for weston loggging
framework rename weston_debug_compositor to weston_log_context to show
the fact that this is not really debug but a logging context.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The printf() format specifier "%m" is a glibc extension to print
the string returned by strerror(errno). While supported by other
libraries (e.g. uClibc and musl), it is not widely portable.
In Weston code the format string is often passed to a logging
function that calls other syscalls before the conversion of "%m"
takes place. If one of such syscall modifies the value in errno,
the conversion of "%m" will incorrectly report the error string
corresponding to the new value of errno.
Remove all the occurrences of the specifier "%m" in Weston code
by using directly the string returned by strerror(errno).
While there, fix some minor indentation issue.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
weston.h is a Weston frontend header, while this is a libweston plugin. A
libweston plugin cannot depend on Weston. Luckily the header is not actually
needed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main idea is to make libweston users use the form
#include <libweston/libweston.h>
instead of the plain
#include <compositor.h>
which is prone to name conflicts. This is reflected both in the installed
files, and the internal header search paths so that Weston would use the exact
same form as an external project using libweston would.
The public headers are moved under a new top-level directory include/ to make
them clearly stand out as special (public API).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This crash was happening *during resizing* of an xwayland window that was destroyed.
Discovered by: John Good @archiesix
[@daniels: Moved tests below declarations.]
Use the pattern to avoid identing everything, when everything in the
file is under the one conditional.
Helps readability.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Meson is a build system, currently implemented in Python, with multiple
output backends, including Ninja and Make. The build file syntax is
clean and easy to read unlike autotools. In practise, configuring and
building with Meson and Ninja has been observed to be much faster than
with autotools. Also cross-building support is excellent.
More information at http://mesonbuild.com
Since moving to Meson requires some changes from users in any case, we
took this opportunity to revamp build options. Most of the build options
still exist, some have changed names or more, and a few have been
dropped. The option to choose the Cairo flavour is not implemented since
for the longest time the Cairo image backend has been the only
recommended one.
This Meson build should be fully functional and it installs everything
an all-enabled autotools build does. Installed pkg-config files have
some minor differences that should be insignificant. Building of some
developer documentation that was never installed with autotools is
missing.
It is expected that the autotools build system will be removed soon
after the next Weston release.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Instead of a compile time choice, offer the XWM debugging messages
through the weston-debug protocol and tool on demand. Users will not
need to recompile weston to get XWM debugging, and it won't flood the
weston log.
The debug scope needs to be initialized in launcher.c for it be
available from start, before the first X11 client tries to connect and
initializes XWM.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
pass the wm_debug scope to weston_debug_scope_printf API to append
the scopename to the timestr
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This is preparation for using the weston-debug infrastructure for
WM_DEBUG. dump_property() may be called from different debugging
contexts and often needs to be prefixed with more information.
An alternative to this patch would be to pass in the weston_debug_scope
as an argument to dump_property(), but then all callers would need to be
converted to weston-debug infra in a single commit.
Therefore require the callers to provide the FILE* to print to.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Write the output of dump_property() out in one log call. When multiple
processes (weston and Xwayland) are writing to the same file, this will
keep the property dump uninterrupted by Xwayland debug prints.
This is also preparation for more development in the same direction.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Very useful for TRANSIENT_FOR property debugging.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Add code to dump CARDINAL arrays from properties. Useful for debugging.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
This (partially) reverts commit bef761796c.
This (partially) reverts commit 4d1cd36c9e.
This (partially) reverts commit 44fc1be913.
This (partially) reverts commit 6b58ea8c43.
The new xwm icon code has proven to be leaky and incomplete, and while
we have patches under consideration to fix the rest of its known problems
they still require changes and review cycles. Currently the known
leaks have been squashed, but it still picks wrong sized icons and
does no scaling, which can lead to very strange rendering. At window
close time the wrong sized icon appears above the window during fade out.
This patch reverts the mostly solid bits and keeps the unfinished
bits behind in favor of a simpler revert than removing the whole
thing.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This reverts commit 332d1892bb.
And re-introduces the bug it was intended to fix, see:
https://lists.freedesktop.org/archives/wayland-devel/2017-December/036402.html
Reverting this because it causes harm to all xwayland clients - the
input region no longer gets adjusted when resizing windows.
start an xterm, resize it larger, you can no longer interact with the
new area of the window (including the server side decor).
Hopefully sort the last leaks introduced in commit 6b58ea8c
The window could be destroyed before it had a frame but after it had an icon
(I could trigger this with firefox), and the window could be assigned an icon
twice before it had a frame (I could trigger this with terminology).
The latter leak was
Reported-by: Scott Moreau <oreaus@gmail.com>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
A memory leak introduced by 6b58ea8c led to me finding a bigger leak,
which is xwm was calling frame_create() without calling frame_destroy().
This meant that the associated icon_surface was not being destroyed,
leaving the destroy handler for it broken. Here we fix this by calling
frame_destroy() when the window is destroyed and free the reply in
the icon_surface destroy handler.
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This reverts commit d2cb711d81.
I missed the call to cairo_image_surface_create_for_data() which assumes
the data will remain present until the cairo surface is destroyed. It
seems the existence of data depends on the reply not being freed.
This will need a more involved fix.
Sorry, I noticed this just seconds after I pushed the patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Fix memory leak introduced by 6b58ea8c. weston_wm_handle_icon() was
calling xcb_get_property_reply() without freeing the reply.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The cairo surface used for the icon must be completely given to the
frame as soon as said frame has been created. To prevent both the
window and the frame from sharing ownership of the icon, we set
window->icon_surface back to NULL right after creating or changing the
frame, only keeping it there when no frame has been created yet.
Fixes https://lists.freedesktop.org/archives/wayland-devel/2018-January/036655.html
Reported-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
commit e7fff215ad made initializing the
selection_listener conditional, but didn't make its clean-up
conditional at shutdown. Simply initializing the listener's list
link at init time makes this harmless.
To see this, run weston -Bheadless-backend.so and then connect to it
with an X client. When killing weston it will attempt shutdown but
die with a segfault.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This fetches the _NET_WM_ICON property of the X11 window, and use the
first image found as the frame icon.
This has been tested with various X11 programs, and improves usability
and user-friendliness a bit.
Changes since v1:
- Changed frame_button_create() to use
frame_button_create_from_surface() internally.
- Removed a check that should never have been commited.
Changes since v2:
- Request UINT32_MAX items instead of 2048, to avoid cutting valid
icons.
- Strengthen checks against malformed input.
- Handle XCB_PROPERTY_DELETE to remove the icon.
- Schedule a repaint if the icon changed.
Changes since v3:
- Keep the previous Cairo surface until the new one has been
successfully loaded.
- Use uint32_t for cardinals. Unsigned is the same type except on
16-bit machines, but uint32_t is clearer.
- Declare length as uint32_t too, like in xcb_get_property_reply_t.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The window frame was created with position and size which include
an offset for margins and shadow. Set the input region to ignore
shadow.
[daniels: Fixed type mismatch, removed unused variable.]
Signed-off-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Tested-by: Scott Moreau <oreaus@gmail.com>
If we configure a window with the same size and wait for the
sync alarm to go off, the resizing is gonna block. The event is
only handled is the size actually changed.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
A single client message can be used to modify two properties at once.
That's why when processing such messages we have to check both the second
and the third data entry for states that we must handle.
Signed-off-by: Ilia Bozhinov <iliyabo@hotmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When we receive configure_notify we should update the surface's
position by calling xwayland_api->set_xwayland(). Otherwise some surfaces
like dnd surfaces from xwayland views are "stuck" at one place. When
setting XWAYLAND state though we should always call view_set_position(),
not just the first time we set this state.
Signed-off-by: Ilia Bozhinov <ammen99@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
xwm would not let X clients change the focus behind the compositor's
back, reverting focus where it's supposed to be when this occurs.
However, X11 grab also issue focus in events, on which some clients
rely and reverting focus in this case braks the client logic (e.g.
combobox menu in gtk+ using the X11 backend).
Check if the focus event is actually coming from a grab or ungrab and
do not revert focus in this case, to avoid breaking clients logic.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This patch uses the new feature proposed for Xwayland in the patch
series https://patchwork.freedesktop.org/series/16610/ .
When the frame window is created, immediately forbid Xwayland commits on
it. This prevents commits before the decorations have been drawn and the
initial pending state has been set. Commits are enabled right after
drawing and setting.
This ensures that the decorations are fully drawn when a window is
mapped. This also solves the initial commit/pending race, but the race
is on again after mapping.
If Xwayland does not implement the needed support, we are just setting a
window property with no effect.
This patch is the final piece for solving T7622, excluding the
_NET_WM_SYNC_REQUEST handling.
Task: https://phabricator.freedesktop.org/T7622
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Normal windows enter the MapRequest handler, which schedules drawing the
decorations. Then Xwayland realizes the window, which ends with a call
to xserver_map_shell_surface(). The decorations are already drawn, no
need to draw them a second time. However, MapRequest handler could not
set the pending state because the weston_surface did not exist at the
time, because it gets created only when Xwayland realizes the window,
which happens after XWM has forwarded the MapWindow in MapRequest
handler. Therefore set the pending state explicitly at the end.
Scheduling had it done much later anyway.
Now that the pending state is set much earlier, it seems to be more
likely that it gets set before Xwayland's first commit is handled. This
means that -geometry command line option of X11 apps already takes the
geometry (decorations) into account. I do not think it is reliable yet,
though.
There is still the race between Xwayland committing and XWM setting the
pending state assuming the very next commit latches it in appropriately.
The race exists not because of Wayland, but because WL_SURFACE_ID comes
via X11, and could be processed after wl_compositor.create_surface and
wl_surface.commit. That commit/pending race is solved by a following patch.
For override-redirect windows weston_wm_window_schedule_repaint()
reduced into a call to weston_wm_window_set_pending_state_OR(), so we
can just call that directly. It should not matter that the call is moved
to the end of the function.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
To me it was not obvious that this call is necessary, so provide some
rationale.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When we as the WM tell the X server to map a window, it gets mapped. We
can start drawing into it immediately. There is no reason to wait for
any other events before drawing the decorations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This comes via Wayland, WL_SURFACE_ID comes via X11. They race. Nice to
get both printed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Having it in a separate function makes it more clear what it is, and
allows it to be called from elsewhere.
This really is the set_pending_state() alternative for override-redirect
windows, because OR windows do not get a frame window created. Also OR
windows will never hit the normal set_pending_state() because
weston_wm_window_schedule_repaint() special-cased windows without a
frame window and returned early without scheduling.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Move the region fini just above the region init. They are a pair and
belong togeether. Split a long line.
Reads better this way. No functional changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Split the function into two:
- weston_wm_window_draw_decoration() that only draws the decorations
with Cairo, and
- weston_wm_window_set_pending_state() which sets up the surface state
to be latches into use on the next commit from Xwayland.
The new weston_wm_window_do_repaint() is the equivalent of the old
weston_wm_window_draw_decorations(), everything still happens the same
way as it was. Just some debug messages have been reworded.
weston_wm_window_read_properties() is moved into
weston_wm_window_do_repaint() because it is not strictly a part of
drawing decorations. The same with resetting repaint_source.
draw_decorations does not need the child position nor xwayland
interface. Also some convenience variables have been eliminated.
set_pending_state code has been un-indented by one level, so the change
is best viewed with whitespace changes ignored.
This patch makes the code more readable, and prepares for calling the
draw_decorations and set_pending_state from different places.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
X11 applications expect -geometry command line option to work for
setting the initial window position, but currently this does not work.
During map, detect X11 windows that set an explicit position. This works
by heuristics: if window position is not 0,0 then it is explicitly
positioned. Legacy fullscreen windows are also at 0,0 but these are
detected earlier.
Explicitly store the window position at map request time to detect
client-positioned windows, and use it as the suggested initial position.
weston_wm_window::x and y have been overwritten due to reparenting when
we eventually need the initial position.
This patch requires that the new set_toplevel_with_position() hook is
implemented in the shell.
Note that this patch is about positioning xwayland toplevels, not
override-redirect windows which are already handled.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add a new entry to the internal interface between the xwayland plugin
and libweston-desktop (or any other desktop protocol implementation).
The new entry is identical to set_toplevel except it carries an absolute
position for the toplevel window.
Following patches will implement this new entry in
libweston-desktop and start using it in XWM.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
To reproduce the problem:
- start weston (x11 backend worked, glamor in Xwayland makes no
difference)
- start xterm
- very very slowly move the pointer in the xterm decorations onto or
away from a button
- the moment the decorations are updated, they will appear incomplete,
e.g. completely without buttons and title text
- if you cause just one more pointer motion event, the decorations will
update to completely drawn appearance
Another way to reproduce the problem is to have an xterm and change its
window title. This is easy if you use a shell prompt that updates the
terminal window title. When the title updates, decorations will be
half-drawn until something happens in XWM.
The fix: flush.
Apparently the drawing commands did not get flushed to the X server
until any other X11 action pushed them through.
xcb_flush() is the real fix here. cairo_surface_flush() is added just
for good measure, because documentation indicates it would be better
used, however it was not strictly necessary to fix the problem in my
experiments.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Tested-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Reviewed-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Use different functions so we cannot load a libweston common module in
weston directly or the other way around.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Obviously unused. Looks like weston_wm_window_activate() is doing that
job.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Changing the opaque region has no immediate effect, therefore there is
no need to mark the view geometry dirty.
The view geometry will be invalidated automatically by the next commit
from Xwayland, in weston_surface_commit_state(). The dirtying did not
apply pending state.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Use wm_log_continue() to avoid printing the timestamp in the middle of a
message.
Print the name of the property that got deleted.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
For every event we handle and that delivers the override-redirect flag,
print it to debug log.
Add a comment to one code path explaining when it gets hit, because it
is unobvious. It also serves as a reminder that we do not handle changes
to the OR flag after Window creation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Move the calls to set_title() and set_pid() out of
weston_wm_window_read_properties() and into the three callers, each
slightly different.
xserver_map_shell_surface(): already calls these functions after
creating the shell surface, so no need to add calls.
weston_wm_handle_map_request(): can be called only on unmapped (in X11)
Windows, so no need to add calls.
weston_wm_window_draw_decoration(): window->shsurf and window->surface
are either both set or both NULL, so the check for window->shsurf is
removed when moving the set_title() and set_pid() calls under a
window->surface check.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The only thing using the frame title is frame_repaint(). Move the call
to frame_set_title() from weston_wm_window_read_properties() into
weston_wm_window_draw_decoration() where the only call to
frame_repaint() is.
Do not check for window->name == NULL, because frame_set_title() handles
NULL just fine. Also, once window->name becomes set, it cannot become
NULL again unless strndup() fails. The name string can be reset to
the empty string in any case.
This change is prompted by future refactoring where at
weston_wm_window_read_properties() time the frame might not have been
created yet.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The props array contained offsets to struct members. It is convenient
for writing static const arrays as you only store a constant offset and
compute the pointer later. However, the array was not static to begin
with, the atoms are not build time constants. We can as well just store
the pointer directly in the array.
Entries that did not use the offset had bogus offsets, producing
pointers to arbitrary fields. They are changed to have a NULL pointer.
If the code unintentionally used the pointer, it will now explode rather
than corrupt memory.
Also explain the use of the #defined constants and #undef them when they
get out of scope. This clearly documents that they are just a convenient
hack to avoid lots of special cases in the function.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The legacy fullscreen state needs to be detected at MapRequest time,
because that is when the X11 client has alredy set up the initial window
state.
Doing it at xserver_map_shell_surface() meant that it would be done as a
response to Xwayland creating the wl_surface and XWM receiving the
WL_SURFACE_ID ClientMessage, whichever came later. At that point the X11
client might still be setting things up in theory, though in practice
most of the X11 communication has already happened when
xserver_map_shell_surface() gets called.
The real reason for this is to clean up xserver_map_shell_surface() from
everything that would affect drawing the decorations. This patch is one
part of that clean-up.
The weston_output_weak_ref logic is not put into compositor.h, because
there are no other users for it at this time. We need to protect against
the output going away.
A side-effect of this patch is that saved_width and saved_height will
now get overwritten also for legacy fullscreen windows. Previously, they
were left to zero as far as I could tell.
NOTE: This stops override-redirect legacy fullscreen windows from being
detected as fullscreen. MapRequest processing does not happen for OR
windows. These windows get detected as type XWAYLAND instead.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Add WM debug prints on map, decoration drawing and geometry setting.
These help see the sequence and timing of operations, when debugging
Xwayland window management glitches.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Helps debugging initial placement problems.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Helps debugging X11 window positioning issues.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Just to keep it hidden so far... A lot of the plumbing necessary to
handle x11->wayland drag and drop is missing, and the current
partial handling gets in the middle for X11 drag-and-drop itself
to work.
The approach is well directed, but needs some further work, till
then, just keep our fake drag-and-drop target hidden. This allows
drag-and-drop to work between X11 clients in Xwayland, and avoids
a crash with (currently unhandled) wl_resource-less data sources.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=94218
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The X11 lock file was somewhat opaque. Into a sized array of 16
characters, we previously read 11 bytes. 61beda653b fixed the parsing of
this input to ensure that we only considered the first 10 bytes: this
has the effect of culling a LF byte at the end of the string.
This commit more explicitly NULLs the entire string before reading, and
trims trailing LF characters only.
It also adds some documentation by way of resizing pid, an explicit size
check on snprintf's return, and comments.
Verified manually that it emits lock files with a trailing \n, as Xorg
does. Also verified manually that it ignores misformatted lock files,
but accepts either \n or \0 in the trailing position.
Related Mutter issue: https://bugzilla.gnome.org/show_bug.cgi?id=774613
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Starting an xterm with no input device led to a crash
because weston_wm_pick_seat() was returning garbage and
weston_wm_selection_init() was trying to use the garbage.
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Patch 139fcabe7c "xwayland: Improve error
checking for strtol call" caused a regression in the X11 unix socket
lock file parsing. Before that patch, only the first 10 characters were
considered for parsing. After the patch, the newline as the 11th
character caused strtol() to stop parsing at the 10th character which
was then considered an error as not the whole input was consumed.
The effect of the regression was that no X11 lock files were ever deemed
stale, hence stale lock files were never removed. Up till now, I have
accumulated 37 lock files, and Weston complaining for each of them on
every start it cannot parse them.
Fix this by terminating the string at the expected newline character.
Also, it looks like 'pid' was being used uninitialized, risking strtol()
reading past the end of the array. This patch fixes that too.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
compositor.h already helpfully defines WL_HIDE_DEPRECATED for us, so we
don't get warnings about wl_buffer (in particular) being deprecated when
we have wayland-server headers defining it as deprecated, and then
wayland-client headers using the type.
Move it to be before all our other includes, so we actually make use of
it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Tested-by: Yong Bakos <ybakos@humanoriented.com>
This silences two warnings:
clients/window.c:2450:20: warning: implicit conversion from enumeration
type 'enum wl_pointer_button_state' to different enumeration type 'enum
frame_button_state' [-Wenum-conversion]
button, state);
^~~~~
clients/window.c:2453:15: warning: implicit conversion from enumeration
type 'enum wl_pointer_button_state' to different enumeration type 'enum
frame_button_state' [-Wenum-conversion]
button, state);
^~~~~
Warning produced by Clang 3.8.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
This updates the error checking for the strtol() call in xwayland's
create_lockfile to match other cases. C.f. cbc05378 and other recent
patches.
A notable difference here is that the existing error checking was
verifying that exactly 10 digits were being read from the lock file,
but the fact that it's 10 digits is just an implementation detail for
how we're writing it. The pid could be a shorter number of digits, and
would just be space-padded on the left.
This change allows the file to contain any number of digits, but it
can't be blank, all of the digits must be numeric, and the resulting
number must be within the accepted range.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The third arg to strtol() specifies the base to assume for the number.
When 0 is passed, as is currently done in option-parser.c, hexadecimal
and octal numbers are permitted and automatically detected and
converted.
This change is an expansion of f6051cbab8
to cover the remaining strtol() calls in Weston, where the routine is
being used to read fds and pids - which are always expressed in base-10.
It also changes the calls in config-parser, used by
weston_config_section_get_int(), which in turn is being used to read
scales, sizes, times, rates, and delays; these are all expressed in
base-10 numbers only.
The benefit of limiting this to base-10 is to eliminate surprises when
parsing numbers from the command line. Also, by making the code
consistent with other usages of strtol, it may make it possible to
factor out the common code in the future.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch follows a similar approach taken to detach the backends from
weston. But instead of passing a configuration struct when loading the
plugin, we use the plugin API registry to register an API, and to get it
in the compositor side. This API allows to spawn the Xwayland process
in the compositor side, and to deal with signal handling. A new
function is added in compositor.c to load and init the xwayland.so
plugin.
Also make sure to re-arm the SIGUSR1 when the X server quits.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
[Pekka: moved xwayland/weston-xwayland.c -> compositor/xwayland.c]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
