We don't have focus-follows-mouse, so it makes more sense to
maximize or fullscreen the surface that has the keyboard focus,
not the one behind the pointer.
We have to move the surface destroy listener around as we track the
currently focused surface. Introduce a helper function,
focus_state_set_focus() for this and use throughout.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73768
Various functions that operate on a weston_surface assume the
surface has a shell_surface. That is, they unconditionally
deref the get_shell_surface() result. Hence, if for some reason
the call to get_shell_surface() returned NULL to those functions then
a segmentation fault would occur and the program would crash. So,
adding an assert(...) on the get_shell_surface() return value adds an
extra sanity check and does not change this behavior. The assert also
adds an extra benefit to the programmer by documenting that the function
expects and requires the weston_surface to have a shell_surface and
would be a program logic error, otherwise.
The assert() also silences some static analyzers about the possible
NULL deref.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
exposay_highlight_surface() is called from exposay_pick(),
exposay_layout(), and exposay_maybe_move() where the esurface
parameter is already validated prior to the call. This makes
the 'esurface' NULL check redundant. This assumes any future
calls to exposay_highlight_surface() will also validate the
'esurface' parameter prior to the call.
This fixes the logic in exposay_highlight_surface so static
analyzers don't complain about the possibility that 'view'
might be NULL deref'd when a 'esurface' == NULL condition is
true.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
When the last window of the X11 compositor is closed during a fade or
while locked, we'll try to start a fade back to the lock screen. However,
if we closed the last window, there are no outputs left and the animation
will try to run with surface->output == NULL.
https://bugs.freedesktop.org/show_bug.cgi?id=73665
This is part of the fix for bug 72540. We cancel the popup grab when the
screensaver kicks in so that the screen unlock dialog can get input events.
The bigger problem is in mesa however, where we try to allocate new buffers
as cairo-gles2 does a gratuituous (but valid) eglMakeCurrent() as we
remove the tooltip or popup-menu.
Since we removed the weston_layer with the regular surfaces, EGL blocks
waiting for a frame event that never comes.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72540
The grab stays alive as long as at least one touch point is down. If touch
point 0 is lifted while other touch points are down, the surface will jump
around when touch point 0 is put down again.
This change marks the grab as inactive once touch point 0 is lifted
and then ignores touch events until all touch points eventually are
lifted and the grab terminates.
https://bugs.freedesktop.org/show_bug.cgi?id=73750
Add a config file option to enable it, but leave it off by default. Exposay
still triggers too many lock-ups or stuck grabs and triggers under X even
when the Wayland window doesn't have keyboard focus.
We now track the child surfaces of a shell surface and the child surfaces
have a pointer back to their parent. We need to clean all this up and
NULL out the childrens parent pointers when a shell surface is destroyed.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72931
The keyboard is too chatty, make it use a dbg() function for logging
which defaults to disabled.
Also drop a noisy fprintf() in input_panel_configure().
It's possible to touch a surface to move it and let go before we get
to common_surface_move(), in which case we don't have a touch focus
when we get there. For pointers, we could click a surface, but have the
surface go away before we get to common_surface_move(), in which
case the button count is non-zero, but we don't have a surface.
In either case we crash, so let's add a check to make sure we still
have a focus surface before we try to move it.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=73448
This fixes the crash when move, rotate or resize binding is activated
while exposay effect is active.
Steps to reproduce:
- activate exposay
- try to rotate the surface with mod + right mouse button
- crash
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72885
We were calling exposay_highlight_surface() inside a wl_list_for_each
loop for a layer, but exposay_highlight_surface() calls activate()
which calls shell_surface_update_layer(), which removes the surface
from its layer and reinserts it, causing an infinite loop.
Call exposay_highlight_surface() outside the for_each to avoid this.
https://bugs.freedesktop.org/show_bug.cgi?id=72404
Similar to 7c4f6cc145, if we don't have
a background image from the desktop-shell client or the touch point
for some other reason doesn't hit a surface we trigger a
segfault as we try to deref the seat->touch->focus NULL pointer.
For touch, another problem could be fudgey calibration that ends up
giving touch coordinates outside the output space.
https://bugs.freedesktop.org/show_bug.cgi?id=72839
Set up X windows that are transient for another window as transient
surfaces in shell.c. This keeps the transient windows on top of their
parent as windows are raised, lowered for fullscreened.
https://bugs.freedesktop.org/show_bug.cgi?id=69443
If a surface is not on any output, scheduling a repaint for it is a no-op.
weston_view_schedule_repaint() schedules repaints for all outputs that
overlap with the surface extents, but if the surface is completely
outside all outputs nothing will be scheduled. Fix this for now by starting
the slide slightly into the output.
The input-panel codes tries to see determine if a buffer has not yet
been attached (or a NULL buffer has been attached), and doesn't map
the input panel surface yet in that case. However, it test for
buffer_ref being NULL, which can happen for other reasons. The right
test is to see if surface->width is 0, which means that either a
buffer hasn't yet been attached or a NULL buffer has been attached.
https://bugs.freedesktop.org/show_bug.cgi?id=72519
If we're not currently showing the input panels, we still need to set the
panel position so that it's set when we later need to show them. This fixes
the initial flicker of the input panel in the wrong position when we first
show it.
If we don't have a background image from the desktop-shell client or the
pointer for some other reason doesn't have a focus we trigger a
segfault as we try to deref the seat->pointer->focus NULL pointer.
https://bugs.freedesktop.org/show_bug.cgi?id=73066
This is still fairly unstable, causes lockups with fullscreen and exposay,
leaves small preview surfaces on-screen if used on the same modifier as
mod-tab. We also only need on mod-tab implementation so lets see if we
can consolidate the current and this alt-tab implementation in 1.5.
https://bugs.freedesktop.org/show_bug.cgi?id=72610
Popup windows are relative to a plain wl_surface, so that custom surfaces
can have popups. This used for the desktop-shell panel for example. Also,
popups should be immediately on top of their parent surface, as they
typically represent an extension of an UI element in the parent surface
such as a combo box or menu.
This reverts commit da704d97fa.
Conflicts:
desktop-shell/shell.c
https://bugs.freedesktop.org/show_bug.cgi?id=72547
If we don't mark the state as changed, we don't copy over next_state to
state and we fail to treat the surface as a transient. In particular,
we give it a random intial position instead of mapping it at the given
parent relative position.
https://bugs.freedesktop.org/show_bug.cgi?id=72532
Set the internal pointer for the client to NULL. This fixes a
segmentation fault at shutdown, where the shell would hang up before
and cause libwayland to call wl_client_destroy(). When the shell was
destroyed later, another call to wl_client_destroy() would cause the
crash.
https://bugs.freedesktop.org/show_bug.cgi?id=72550
Surfaces that are created by clients get their size automatically updated
by the attach/commit. Surfaces created directly by shells (such as black
surfaces) sometimes need to be manually resized. This function allows you
to do that while being somewhat less messy than messing with the internals
of weston_surface manually.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
If the saved position for a fullscreen or maximized output view is in an
output that has been unplugged, the coordinates don't make sense
anymore. In that case, invalidate them and use the initial position
algorithm when changing them back to the basic state.
Signed-off-by: Zhang, Xiong Y <xiong.y.zhang@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The surface type now no longer changes and we track pending state changes in
next_state. Instead of testing type != next_type to detect changes in
state, we just look at state_changed.
An xwayland surface corresponds to a override-redirect window under X,
which is typically a menu or a popup window. They typically appear
with a keyboard and mouse grab and by nature of being override-redirect
these window can appear anywhere on screen and in the stack.
We need to resort to heuristics to decide where to place the
override-redirect in our surface stack, and for now we'll just put it on
top of everything. That's going to be correct for almost all cases of
clicking to open a menu, but we can revisit and refine if we run into
a case that needs better handling.
Just as for set_maximized() we can move the setting of the fullscreen and
state_changed flags into the common set_fullscreen() function. This
function is also used from the xwayland wm to set fullscreen windows, and
with this change that now works again.
We can set the maximized and state_changed flags in set_maximized(),
which is shared between shell_surface_set_maximized() and
xdg_surface_set_maximized().
Emilio Pozuelo Monfort
Kristian Høgsberg
Ricardo Vieira
U. Artie Eoff
Rafal Mielniczuk
Jason Ekstrand
Ander Conselvan de Oliveira
Zhang, Xiong Y
Giulio Camuffo
Jasper St. Pierre