Exposay provides window overview functions which, when a key which
produces the binding modifier is pressed on its own, scales all
currently-open windows down to be shown overlaid on the desktop,
providing keyboard and mouse navigation to be able to switch window
focus.
[pochu: rebased, ported to weston_view]
Add an animation which moves a surface to a new location, at the same
time as also rescaling it to a different size from the origin, rather
than the existing scale animation which resizes from the centre.
[pochu: rebased, ported to weston_view]
Add the ability to bind to modifiers; the binding is armed when a key
which sets the requested modifier is pressed, and triggered if the key
is released with no other keys having been pressed in the meantime, as
well as mouse buttons or scroll axes.
This only works for direct modifiers (e.g. Shift and Alt), not modifiers
which latch or lock.
[pochu: rebased]
When enabled, this will make all but the keyboard-focused window dim.
Also the background gets dimmed, if there are any windows open. The
panel is not dimmed.
When the keyboard focus changes, the change in dimming is animated.
The dimming is implemented with transparent solid-color surfaces, two at
most. The net effect of two overlapping dim surfaces is kept constant
during animations (stable fade animation).
There is a new weston.ini option "focus-animation", that defaults to
none, and can be set to "dim-layer" to enable the focus change
animation.
[pq: Sliced, squashed, and rebased the patch series. Fixed surface alpha
interaction with the switcher. Wrote the commit message.]
[pochu: rebased, ported to weston_view]
This reverts commit 2396aec684.
This exact version of the sub-surface protocol has been copied into
Wayland core. Therefore it must be removed from here to avoid build
conflicts and useless duplication.
No other changes to sub-surface protocol consumers are needed, the
identical API is now offered by libwayland-client and libwayland-server.
The commit adding sub-surfaces to Wayland is:
Author: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
protocol: add sub-surfaces to the core
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The signal will be emitted after the pointer is moved. A shell plugin
can listen to the signal and activate certain effects when the pointer
touches the screen corners, for instance.
weston_view_update_transform() will post damage in the old and new
positions of the view and thus make sure we always repaint properly.
In particular, in bug 66133, the test suite moves the surface off
any output and weston_surface_schedule_repaint() in commit fails to
do anything, since the surface is not on any output.
After changing view geometry, we have to either call
weston_compositor_schedule_repaint(), which is what shell.c typically
does, though that repaints all outputs, or call
weston_view_update_transform() to force update the transformation
and queue repaints on affected outputs.
https://bugs.freedesktop.org/show_bug.cgi?id=66133
We always want a repaint if the view was damaged or changed. In
particular, we want weston_view_update_transform() to schedule a
repaint for the old and new position if we change the view transform.
It seems that this was only used by the popup menu infrastructure,
which can handle this all on its own. Implementing e.g. transients
in the future can be done with a simple xdg_shell_set_transient_for.
This wraps all accesses to an SHM buffer between wl_shm_buffer_begin
and end so that wayland-shm can install a handler for SIGBUS and catch
attempts to pass the compositor a buffer that is too small.
This adds fullscreen support to the wayland backend. You can make any
output fullscreen by the shortcut CTRL+ALT+F. You can also run weston with
the --fullscreen option which causes it to create a single fullscreen
output.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This cleans up the configuration and command parsing and separates it from
compositor/output initialization.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This makes button handling more correct concerning drags. Also,
frame_pointer_button returns the original button location in the case of a
release. This makes filtering of button events much easier for users of
the cair-util frame code.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This commit makes the wayland backend search through the config for
[output] sections with names starting with "WL" and create outputs
accordingly. Outputs created due to the config file support mode, scale,
and transform parameters. It also listens for the --output-count
command-line option.
This brings the wayland backend almost up to par, in terms of functionality
with the X11 backend.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Both the Pixman renderer and the X11 backend contained effectively the same
region transformation code. This commit adds a weston_transformed_region
function and changes pixman-renderer and compositor-x11 to use it.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The output is renamed "output" from "x11_output" and the input coordinates
are changed to wl_fixed_t from int. This way it is useable in
compositor-wayland as well as compositor-x11 and evdev.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The only user for this was the wayland backend with the GL renderer. It is
not needed in the Pixman renderer because you can easily create subimages.
All of the fancy output matrix calculations can be replaced by a single
glViewport call. Also, it didn't work with outputs located anywhere but
(0, 0) and I'm pretty sure output transformed outputs would break it too.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This adds a window frame with a close button. Similar to the X11 backend,
The window supports dragging but not resizing.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The first advantage of this new API is that it is per-output instead of
global to the gl_renderer instance. This means that different windows can
have different titles, different button states, etc. The new api also uses
four textures (one for each side) instead of one. This allows you to draw
real borders with text and buttons in them instead of a simple image that
gets streached.
Images will be scaled as needed, so the right and left can be one pixel
tall if desired.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The logic here broke at some point so that we would only update the
input region for non-fullscreen windows. Thus, a fullscreen window would
be stuck with whatever size the most recent non-fullscreen size was.
https://bugs.freedesktop.org/show_bug.cgi?id=69219
This fixes the problem where animations will wait to play until input is
received. In general, it also makes the backend far more responsive.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
https://bugs.freedesktop.org/show_bug.cgi?id=68221
On shutdown, we can risk having a pending vt switch that we normally
handle in the vt signal handler. However as we put the vt back in VT_AUTO
mode, the pending VT switch will go through and if we haven't dropped
drm master at that point, we could switch to another display server
without dropping drm master. That will typically crash the other server,
so let's try to make sure we don't do that.
https://bugs.freedesktop.org/show_bug.cgi?id=70877
If the seat or tty doesn't match we return with r == 0, which looks like
success to weston_launcher_connect(), which then fails to fall back
to the legacy path.
https://bugs.freedesktop.org/show_bug.cgi?id=70876
Otherwise we don't repaint with the final state of the surface and
we're stuck with the second-to-last frame of the animation until
something else (moving the mouse or such) triggers a redraw.
https://bugs.freedesktop.org/show_bug.cgi?id=70930
get_animation_type() parses "none", "zoom" and "fade" but for the
startup animation, we only support "none" and "fade". If we get "zoom"
just fall back to "none" like we do for all unrecognized strings.
https://bugs.freedesktop.org/show_bug.cgi?id=71006
We used to ungrab first to stop any existing grab and then grab after
showing the menu. That was broken in c680e90489, which
moved the ungrab down below the grab, and as a result menus are now
shown without a grab. This commit moves the grab back up.
A grab can potentially allocate memory and would normally end the grab
itself, freeing the allocated memory in the process. However at in some
situations the compositor may want to abort a grab. The grab owner still
needs to free some memory and abort the grab properly. To do this a new
function 'cancel' is introduced in all the grab interfaces instructing
the grabs owner to abort the grab.
This patch also hooks up grab cancelling to seat device releasing and
when the compositor looses focus, which would potentially leak memory
before.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>