Otherwise, it means the X11 compositor depends on another library to
pull xcb-shm (cairo?), which is not always the case. Here I end up with:
[01:54:38.970] Failed to load module:
$prefix/lib/weston/x11-backend.so: undefined symbol: xcb_shm_id
This ensures the popup_grab.initial_up field isn't reset to 0
if the popup was not opened because of a mouse press but because
of moving the mouse with a popup already open. Not doing so will
make the first click outside the client area go ignored.
This patch implements a popup stack. When the first popup is opened
the grab is started, and it is added to a list. Further popups will
be added to this list but the grab won't change. When a popup is
closed it is removed from the list and, if it is now empty, the grab
is ended.
A click outside the client area will send the popup_done event to
all the popups in the list, and the grab will end.
Before this commit, weston-launch returned 0 if weston was killed by a
signal. This makes it hard to automatically test weston by using
weston-launch, as there is no way to know why weston was terminated.
This commit makes weston-launch return 10+N instead, where N is the code
of the signal that terminated weston. 10 was chosen because it allows a
script to distinguish it from the case that weston-launch itself was
killed by a signal (128+N), and does not overlap the standard exit codes
defined in sysexits.h.
Partial fix for https://bugs.freedesktop.org/show_bug.cgi?id=60935. I
can't reproduce the SIGHUP using the fbdev backend.
v3: better commit message.
Resolve a bad frame visible when maximizing toytoolkit programs with the the
maximize button in decorations. Windows now use wl_display.sync requests to
wait for a maximize to finish before drawing again, following suggestions from
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007650.html
Surface will preserve its rotation transformation when maximizing, which
will cause inconsistencies (eg. no window shadows drawn)
This patch removes rotation from maximized surface and restore it when
unmaximizing (just like in fullscreen mode)
To remain consisten with client side window, which blocks moving and
resizing of window in maximized state, we should do so on the compositor
side as well.
(until there is some unmaximize notification from server, which will
allow window to start drawing shadows and revert itself to toplevel
state)
Implements surface transform inheritance. A 'parent' pointer is added to
weston_surface::geometry, and is automatically used by
weston_surface_update_transform(). When updating the transform, the
parent transform is updated as needed, too.
shell_map_popup() is converted to use the new
weston_surface_set_transform_parent() function. Now, if we moved the
popup's parent surface while the popup is open, the popup surface will
stick to the parent properly.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Instead of directly setting the dirty flag on weston_surface geometry,
use a function for that.
This allows us to hook into geometry dirtying in a following patch.
Also add comments to weston_surface fields, whose modification causes
transform state to become outdated.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Remove redundant geometry dirtying from surface_commit() to simplify
further changes.
This code was added in commit 5df8ecac5d
"compositor: Fix partial repaints"
as the fix to:
https://bugs.freedesktop.org/show_bug.cgi?id=56538
The issue fixed by that commit was making the geometry dirty on every
attach, which caused full-surface repaints every time. The bug was
probably introduced by the opaque region changes during implementing
wl_surface.commit. The mentioned commit fixes the opaque handling by
comparing the new and old regions.
However, the commit also introduces additional checks that set
geometry.dirty. In the current code base, this should be unnecessary.
If the pending.sx or pending.sy are not zero, or if the surface size
changes, the configure() hook is responsible for applying the new
values, and so also marking the geometry dirty.
The configure() hook is only called, if there has been a new
wl_surface.attach. Nothing else can change these variables, so this
should be enough.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
When an axis (scroll) event results in a key binding function
being executed, eat the scroll event so the underlying window
doesn't receive it.
Thanks to Scott Moreau for helping me solve this.
Now that we have EXT_buffer_age in mesa, we should stop assuming double
buffering and use the buffer age instead.
Note: this will cause system without the extension to repaint the whole
screen every frame.
Before this change, surface->clip would contain the region of this the
surface that is obscured by opaque containing of other surfaces in any
plane. If a surface was obscured only by a surface in another plane and
the renderer was told to draw that region, the rendering would be
clipped because of that.
This patch changes the clip to be plane specific, so that it contains
only the region of the surface obscured by other surfaces in the same
plane. We also calculate a per plane clip, so that we don't tell the
renderer to draw regions of the primary plane that are obscured by
other planes. This damage remains on the primary plane until the its
clip changes so that they are not obscured anymore.
The core uses this region to clear from the primary plane damage the
area that was repainted. If we add the old buffer damage to that, it
may end up clearing more damage from the primary plane than it was
intended.
The current semantics would implicitly attach the most recently attached
buffer at commit time and send a release event when the buffer enventually
was released. The implicit attach is a little too subtle though and this
patch changes the semantics to always only send release events in response
to an attach event. As a consequence, once a compositor releases a buffer,
it no longer has a reference to it and wl_surfcea.damage is undefined.
Thus, the client side visible change is that damage request must always
be preceeded by a wl_surface.attach request, to ensure there's a valid buffer,
even if that means attaching the same buffer again.
Nothing else calls weston_buffer_post_release and the ref-counting and
sending the release event is essentially what weston_buffer_reference is
all about.
We subtract the screen space opaque region from the transformed surface
region. That's going to fail for when we're scaling up a surface, since
the surface bounding box for the scaled up surface is going to be bigger
than the opaque region. Instead, subtract the surface-space opaque region
from a 0,0 - width,height region and see if that's empty.
move_client() needs to attach the buffer, even if it was attached already,
because since 184df50 configure() will be called only on newly attached
surfaces, but the one that sets the test surface position is the configure
function.
We never init this, so we need to copy over the position matrix and then
overwrite the translation entries to make sure we have a valid matrix.
Thanks to Pekka for spotting this (twice).
This way the shell can know when a surface has been unmapped by
checking the value returned by weston_surface_is_mapped(surface).
The configure handlers have now width and height parameters, so
they do not need anymore to check manually the buffer size.
If a surface's buffer is NULL the width and height passed to the
configure are both 0.
Configure is now only called after an attach. The variable
weston_surface.pending.newly_attached is set to 1 on attach, and
after the configure call is reset to 0.
The issue was that touch::down event from the compositor to client apps
would send the previous motion events coordinates and this obviously made
the client do the wrong thing. This happened because we were not waiting
for a SYN event to come from evdev before sending down, motion or up events.
https://bugs.freedesktop.org/show_bug.cgi?id=51909
If there was a fullscreen surface using driver mode when a vt switch is
triggered, but something caused it to be gone when switching back (such
as the client being killed), a call to drm_output_switch_mode() is made
to restore the old mode, and that sets the output's current drm_fb to
NULL, so that the new mode is set drm_output_repaint(). This led to a
crash in vt_func(), because it tried to access output->current for
restoring the old mode.
Fix this by not setting the mode if there's no current fb. Instead,
schedule a repaint so that the mode is set in drm_output_repaint().
https://bugs.freedesktop.org/show_bug.cgi?id=60675
