Touch-wise, those are essentially giant touchpads, but have no buttons
associated to the "touchpad" device (There may be pad buttons, but
those are not mouse buttons).
Without tap-to-click/drag, touch in those devices is somewhat useless
out of the box. Have them always enable these features, despite the
setting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/968
From `meta_cullable_cull_out`:
```
Actors that may have fully opaque parts should also subtract out a region
that is fully opaque from @unobscured_region and @clip_region.
```
As we do no check for the intersection of these two elsewhere in the code,
let's substract from the clip region, too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/985
FLT_MIN is the smallest *positive* number above 0 that can be
represented as floating point number. If this is used to initialize the
maximum x/y coordinates of a rectangle, this will always be used if all
x/y coordinates of the rectangle are negative. This means that picking
at 0,0 will always be a hit for such rectangles.
Since mutter creates such a window for server side decorations on X11,
this window will always be picked at 0,0 preventing clicking/hovering
the activities button in gnome-shell at that coordinate.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/893
Using the same scale for the window as the
logical monitor only works correctly when having
the experimental 'scale-monitor-framebuffer'
feature enabled.
Without this experimental feature, the stream
will contain a black screen, where the actual
window only takes a small part of it.
Therefore, use a scale of 1 for the non-
experimental case.
Patch is based on commit 3fa6a92cc5.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/976
At this point only the gl driver is at all aware of the difference
between core and compat contexts. COGL_PRIVATE_FEATURE_GL_FIXED is also
now quite misnamed, since we're using the GLSL pipeline even for pre-GL3
contexts. Remove the private feature and handle the few remaining
differences by checking the driver class inside the gl driver.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/973
There's quite a bit of CoglContext that properly belongs to the driver.
Add some hooks to allow the context to create/destroy such state. We
don't have driver-private storage in the CoglContext yet, though we
probably should.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/973
Podman can also be used to create the image. The only thing to keep in
mind with podman is to add --format docker, so that the image will be
compatible with all CI runners.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/966
'xwayland: Do not queue frame callbacks unconditionally' changed the
frame callback behavior of Xwayland surfaces so that they behave the
same way as other actor surfaces (e.g. xdg-shell ones), except for the
case when they are initially assigned.
Remove this special casing as well including the now incorrect comment,
so that the Xwayland surfaces behave the same as the others in this
regard also when assigning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/964
The vfunc is not called when a surface commits its state, but when the
state is applied. Make this clearer by changing the name to
"apply_state" (and "pre_apply_state").
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
This changes how asynchronous window configuration works. Prior to this
commit, it worked by MetaWindowWayland remembering the last
configuration it sent, then when the Wayland client got back to it, it
tried to figure out whether it was a acknowledgment of the configuration
or not, and finish the move. This failed if the client had acknowledged
a configuration older than the last one sent, and it had hacks to
somewhat deal with wl_shell's lack of configuration serial numbers.
This commits scraps that and makes the MetaWindowWayland take ownership
of sent configurations, including generating serial numbers. The
wl_shell implementation is changed to emulate serial numbers (assuming
each commit acknowledges the last sent configure event). Each
configuration sent to the client is kept around until the client one. At
this point, the position used for that particular configuration is used
when applying the acknowledged state, meaning cases where we have
already sent a new configuration when the client acknowledges a previous
one, we'll still use the correct position for the window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
In Wayland, window configuration is asynchronous. Window geometry is
constrained, the constrained geometry is sent to the client, and the
client will adapt its surface and acknowledge the configuration. When
acknowledged, we shouldn't reconstrain again, as that may invalidate the
constraint calculated for the configured size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
Historically, wl_shell clients used to pretend the input region was
equivalent to the window geometry, so for "correctness" lets do that
here too. This makes wl_shell clients with drop shadow behave marginally
better than before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
This moves the cached subsurface surface state into the generic
MetaWaylandSurface namespace. Eventually it'll be used by other surface
roles which as well aim to implement synhcronization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The name didn't communicate it was about surface state, and it somewhat
confusingly had the name "pending" in it, which could be confused with
the fact that while it's used to collect pending state, it's also used
to cache previously committed pending state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
With the eventual aim of exposing the internals of MetaWaylandSurface
outside of meta-wayland-surface.c, make users of the pending state use a
helper to fetch it. While at it, rename the struct field to something
more descriptive.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The intention of meta_window_wayland_move_resize() is to finish a
move-resize requested previously, e.g. by a state change, or a
interactive resize. Make the function name carry this intention, by
renaming it to meta_window_wayland_finish_move_resize().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
Presumably this function is supposed to be like
meta_kms_impl_simple_handle_page_flip_callback() but the condition in the
if-statement is inverted. Fix the inversion to make these two functions look
alike.
This is part 2 of 2 fixing a complete desktop freeze when drmModePageFlip()
fails with EINVAL and the fallback to drmModeSetCrtc() succeeds but the success
is not registered correctly as completed "flip". The freeze occurs under
wait_for_pending_flips() which calls down into meta_kms_impl_device_dispatch()
which ends up poll()'ing the DRM fd even though drmModeSetCrtc() will not
produce a DRM event, hence the poll() never returns. The freeze was observed
when hotplugging a DisplayLink dock for the first time on Ubuntu 19.10.
This patch makes meta_set_fallback_feedback_idle() actually end up calling into
notify_view_crtc_presented() which decrements
secondary_gpu_state->pending_flips so that wait_for_pending_flips() can finish.
CC stable: gnome-3-34
https://gitlab.gnome.org/GNOME/mutter/merge_requests/953
mode_set_fallback() schedules a call to mode_set_fallback_feedback_idle(), but
it is possible for Mutter to repaint before the idle callbacks are dispatched.
If that happens, mode_set_fallback_feedback_idle() does not get called before
Mutter enters wait_for_pending_flips(), leading to a deadlock.
Add the needed interfaces so that meta_kms_device_dispatch_sync() can flush all
the implementation idle callbacks before it checks if any "events" are
available. This prevents the deadlock by ensuring
mode_set_fallback_feedback_idle() does get called before potentially waiting
for actual DRM events.
Presumably this call would not be needed if the implementation was running in
its own thread, since it would eventually dispatch its idle callbacks before
going to sleep polling on the DRM fd. This call might even be unnecessary
overhead in that case, synchronizing with the implementation thread needlessly.
But the thread does not exist yet, so this is needed for now.
This is part 1 of 2 fixing a complete desktop freeze when drmModePageFlip()
fails with EINVAL and the fallback to drmModeSetCrtc() succeeds but the success
is not registered correctly as completed "flip". The freeze occurs under
wait_for_pending_flips() which calls down into meta_kms_impl_device_dispatch()
which ends up poll()'ing the DRM fd even though drmModeSetCrtc() will not
produce a DRM event, hence the poll() never returns. The freeze was observed
when hotplugging a DisplayLink dock for the first time on Ubuntu 19.10.
CC stable: gnome-3-34
https://gitlab.gnome.org/GNOME/mutter/merge_requests/953
