Commit Graph

28131 Commits

Author SHA1 Message Date
Olivier Fourdan
6438919a89 window: Add "is_focus_async" API
X11 clients can use different models of input handling, of which some
may not result focus being set synchronously.

For such clients, meta_focus_window() will not change the focus itself
but rely on the client itself to set the input focus on the desired
window.

Add a new MetaWindow API to check when dealing with such a window.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
2021-02-23 11:08:59 +00:00
Jonas Ådahl
9de36fed4d virtual-input-device/native: Verify device cleanup in impl_state_free()
We free it in the task function, so it's already NULL when freeing the
state struct. Change the redudant unref to a NULL check warning.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
2021-02-23 10:05:32 +00:00
Jonas Ådahl
671bda2509 virtual-input-device/native: Emit added/removed events
Without these devices, things that depend on the existance of input
device classes won't know about the existance of e.g. pointer devices,
if the only pointer device is from a virtual one.

This requires handling situations where e.g. a device doesn't have a
device node thus can't be matched against a udev device.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
2021-02-23 10:05:32 +00:00
Jonas Ådahl
5e34ae2154 backend: Only create idle monitors for added physical input devices
The rest of the things we do aren't applicable, e.g. mapping tablet
devices/tools to monitors and hiding cursors.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
2021-02-23 10:05:32 +00:00
Jonas Ådahl
e6b70f1a2b seat-impl: Dispatch source also when there are already queued events
Libinput will queue a few initial events when a seat is assigned to the
udev backend; a result of it probing udev adding detected devices. For
us to see these events, we need to dispatch libinput before going idle,
as nothing will show up on the libinput file descriptor until something
else (e.g. keyboard event or mouse movement) wakes us up.

Do this by adding a prepare() function to the libinput GSource, that
checks whether there are any events in the queue already, and return
TRUE if so is the case, causing us to dispatch before going fully idle.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
2021-02-23 10:05:32 +00:00
Pascal Nowack
9b5fb1b593 remote-desktop: Clarify the type of keycode for NotifyKeyboardKeycode()
The API for NotifyKeyboardKeycode() does not mention what type of
keycode is expected to be submitted.
So, clarify in the API that the keycode to submit is expected to be an
evdev keycode.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1732>
2021-02-23 08:18:05 +00:00
Pascal Nowack
72cfe9b3fd backends/x11: Interpret keycode correctly
Currently, when a remote desktop user submits a keycode, it will be
interpreted differently, when using the x11 session, instead of a
wayland session.
In a wayland session, submitting a keycode will have the expected
result (as if the key was pressed locally).
In a x11 session, this is not the case. Instead of getting the expected
key, some other key will be pressed (or sometimes even none).
The reason for this is that the native backend interprets the keycode
as evdev keycode and the x11 backend interprets the keycode as xkb
keycode.

To ensure that both backends produce the same behaviour when submitting
a keycode, fix the x11 backend to always interpret the keycode as evdev
keycode, instead of a xkb keycode.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1732>
2021-02-23 08:18:05 +00:00
Pascal Nowack
ff48f6c26b remote-desktop: Fix typo in API description
For NotifyKeyboardKeycode() the API user submits keycodes instead of
keysyms.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1732>
2021-02-23 08:18:05 +00:00
Florian Müllner
c90690c46d Post-release version bump 2021-02-22 15:52:04 +01:00
Florian Müllner
23f45645da Tag release 40.beta
Update NEWS.
2021-02-22 15:44:43 +01:00
Robert Mader
aa6b7ed468 monitor-manager-xrandr: Change g_memdup() to g_memdup2()
This was propably overlooked in 30e1c51b33

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
2021-02-22 13:52:27 +01:00
Robert Mader
6eeeffdc68 src: Stop using GSlice
It has been inofficially deprecated for years, is known to cause issues
with valgrind and potentially hides memory corruption.
Lets stop using it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
2021-02-22 13:52:27 +01:00
Robert Mader
8b977e9046 clutter: Stop using GSlice
It has been inofficially deprecated for years, is known to cause issues
with valgrind and potentially hides memory corruption.
Lets stop using it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
2021-02-22 13:52:27 +01:00
Robert Mader
df4508e8cf cogl: Stop using GSlice
It has been inofficially deprecated for years, is known to cause issues
with valgrind and potentially hides memory corruption.
Lets stop using it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
2021-02-22 13:51:30 +01:00
Aurimas Černius
ddca606b58 Updated Lithuanian translation 2021-02-21 22:00:25 +02:00
Kukuh Syafaat
5c40e8169e Update Indonesian translation 2021-02-21 13:29:30 +00:00
Jonas Dreßler
9512d58c28 display: Don't add MetaDisplay argument to grab-op-* signals twice
GObject signals pass the emitting GObject as the first argument to
signal handler callbacks. When refactoring the grab-op-begin/end signals
to remove MetaScreen with commit 1d5e37050d,
the "screen" argument was replaced with a "display" argument instead of
being removed completely. This made us call the signal handlers with two
identical MetaDisplay arguments, which is very confusing and actually
wasn't handled in a grab-op-begin handler in gnome-shell.

So fix this by not adding the MetaDisplay as an argument to those
signals, GObject will take care of that for us.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1734>
2021-02-19 14:52:22 +01:00
Jonas Dreßler
5527b6e483 background-content: Add support for rounded clipping when drawing
We're going to round the workspace backgrounds in the new overview for
gnome-shell 40.

So far corner-rounding was only possible for StWidgets because the
rounded clipping was done using cairo drawing. We now need rounded
clipping for ClutterActors too because backgrounds are drawn using
ClutterActors (or more specifically a ClutterContent). To implement
that, first a ClutterOffscreenEffect subclass together with a fragment
shader from GSK (see gskSetOutputColor() [1] in the GSK GL renderer
code) was investigated, and while that was generic and worked quite
well, it was extremely slow for the case of drawing wallpapers because
of all the FBOs that had to be allocated.

This is the new, more performant approach: Use the same fragment shader,
but perform the rounded clipping right in MetaBackgroundContent while
we're painting the wallpaper. This has almost no performance impact,
with the downside of not being a generic solution.

To allow for rounded clipping not only at the edges of the wallpaper,
but using any given bounding rectangle, the API exposes not only the
radius, but also a bounding rect.

[1] https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gsk/resources/glsl/preamble.fs.glsl

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1717>
2021-02-18 20:26:42 +00:00
Matej Urbančič
40021c9f00 Update Slovenian translation 2021-02-18 20:18:06 +00:00
Jonas Ådahl
7ddbcd1fd2 cogl/journal: Don't sometimes hold a ref on the framebuffer
d42f1873fc introduced a semi circular
reference between the CoglFramebuffer, and CoglJournal, where
CoglJournal would keep a reference on the CoglFramebuffer when there
were any entries in the journal log.

To avoid risking leaking these objects indefinitely, when freeing
objects without doing anything that triggered a flush, CoglFramebuffer
had a "filter" on cogl_object_unref() calls, which knew
about under what conditions CoglJournal had a reference to it. When it
could detect that there were only the journal itself holding such a
reference, it'd flush the journal, effectively releasing the reference
the journal held, thus freeing itself, as well as the journal.

When CoglFramebuffer was ported to be implemented using GObject instead
of CoglObject, this "filter" was missed, causing not only awkward but
infrequent leaks, but also situations where we'd flush journals when
only the journal itself held the last reference to the framebuffer,
meaning the journal would free the framebuffer, thus itself, in the
middle of flushing, causing memory corruption and crashes.

A way to detect this, by asserting on CoglObject reference count during
flush, is by adding the `g_assert()` as described below, which will
assert instead cause memory corruption.

void
_cogl_journal_flush (CoglJournal *journal
{
   ...
   _cogl_journal_discard (journal);
+  g_assert (journal->_parent.ref_count > 0);
   ...
}

Fix this by making CoglFramebuffer the owner of the journal, which it
already was, and remove any circle referencing that was there before, as
it is not needed given that the CoglFramebuffer pointer is guaranteed to
be valid for the lifetime of CoglJournal as the framebuffer is the owner
of the journal.

However, to not miss flushing before tearing down, which is important as
this flushes painting calls to the driver that is important for e.g.
using the result of those journal entries, flush the journal the first
time cogl_framebuffer_dispose() is called, before doing anything else.

This also adds a test case. Without having broken the circular
reference, the test would fail on g_assert_null (offscreen), as it would
have been "leaked" at this point, but the actual memory corruption would
be a result of the `cogl_texture_get_data()` call, which flushes the
framebuffer, and causes the 'mid-flush' destruction of the journal
described above. Note that the texture keeps track of dependent
framebuffers, but it does not hold any references to them.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1474
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1735>
2021-02-18 16:59:00 +00:00
Pascal Nowack
7076945488 remote-desktop: Document NotifyPointerAxis() more explicit
Currently, the documentation for NotifyPointerAxis() just mentions that
a smooth scroll event is emitted.
However, this is not entirely correct. For each NotifyPointerAxis(),
mutter emits an emulated discrete scrolling event based on the
submitted accumulated smooth scrolling deltas.
Additionally, it doesn't mention how the motion deltas need to be
interpreted.

So, document the NotifyPointerAxis() notification better by mentioning
the emulation of discrete scroll events, how these discrete scroll
events are calculated and how the motion deltas need to be interpreted.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
2021-02-17 21:47:00 +01:00
Pascal Nowack
c77e943ce2 backends/native: Handle triple resolution mouse wheels better
When a remote desktop user emits a virtual smooth scrolling event, a
smooth scroll event, that is not emulated, is emitted and on occasion
a discrete scroll event, that is emulated, is emitted.
As base for the discrete scrolling event, the smooth scrolling steps
are accumulated.
When the accumulated smooth scrolling steps surpass the
DISCRETE_SCROLL_STEP, the discrete scrolling event is emitted.

Currently, mutter uses for DISCRETE_SCROLL_STEP the value 10, which is
a terrible value to work with, especially for high resolution mouse
wheels.
When a triple resolution mouse wheel is used, each scrolling step will
have the value 3 1/3.
Three of such events won't however surpass the DISCRETE_SCROLL_STEP.

To fix this situation, add DBL_EPSILON to the calculation step, when
checking for the discrete scroll event to ensure that 3 smooth scroll
events, with each having the value 3 1/3, emit a discrete scrolling
event.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
2021-02-17 21:39:03 +01:00
Pascal Nowack
a5d692582d backends/x11: Emit discrete scroll events for accumulated smooth events
MetaVirtualInputDeviceX11 currently doesn't handle smooth scroll events
at all.
So, if a user of the remote desktop API uses smooth scroll events, then
only the wayland backend handles these events.
The user of the remote desktop API however, might not know which
backend is being used and actually the user should not even have to
care about it.

Actual smooth events cannot be emulated in the X11 events.
What can be done however is accumulating smooth events and then when
the accumulated steps surpass the DISCRETE_SCROLL_STEP value, emit a
discrete scroll event.
So, do exactly that, to make smooth scroll events work when the remote
desktop API is used with the x11 backend.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
2021-02-17 21:39:03 +01:00
Jordi Mas
64834aee23 Update Catalan translation 2021-02-17 20:34:21 +01:00
Jonas Dreßler
1922896f07 clutter: Also pick on TOUCH_BEGIN events
With 734a185915 an optimization was
introduced to only pick on events which can actually cause the pointer
to move. In case of touch events, the first event (TOUCH_BEGIN) will
already move the touchpoint though, and we'll send our crossing
CLUTTER_ENTER event to the actor this TOUCH_BEGIN happened on.

So fix this embarrassing bug that caused touch input to break by also
picking to find an event-actor on TOUCH_BEGIN events.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1733>
2021-02-16 10:01:22 +01:00
Emin Tufan Çetin
70cfccd9e2 Update Turkish translation 2021-02-15 14:16:19 +00:00
Jonas Dreßler
734a185915 clutter: Only pick on motion or touch update events
Aside from ENTER/LEAVE, there are only two kinds of events that can move
the pointer, motion events and touch update events. Everything else
keeps the pointer at it's current position.

The reason we pick inside _clutter_process_event_details() is that we
want to set the event actor. Now if an event can't move the pointer, it
also can't change the event actor (well, it can subsequently by
triggering changes to the scenegraph, but that's handled elsewhere), so
there's no need to pick a new event actor when we get those events.
Instead, simply reuse the actor that's already associated with the
current input device as the event actor for non MOTION/TOUCH_UPDATE
events.

Events where a device or a touchpoint goes away (like DEVICE_REMOVED or
TOUCH_END/CANCEL) also affect picking, they don't need a repick, but
instead the actor associated with the device/touchpoint needs to be
unassociated. This is ensured by invoking remove_device_for_event() on
those events and will not be affected by this change.

This should improve performance while scrolling quite a bit, since
scroll events come in unthrottled and we now no longer do a repick on
each one of those.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1729>
2021-02-15 12:24:49 +00:00
Jonas Dreßler
d5b69d9cc0 clutter: Use event source directly for debug message
No need to assign things to a separate variable there, let's just read
event->any.source directly instead.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1729>
2021-02-15 12:24:49 +00:00
Daniel Mustieles
fe96778161 Updated Spanish translation 2021-02-15 10:49:21 +01:00
Daniel van Vugt
7e32c4196e clutter/stage-view: Reimplement CLUTTER_SHOW_FPS
Since a9a9a0d1c5 it didn't print anything. Now we reimplement it to
show FPS to a higher precision than in 3.36, add update/render times,
and separate stats per view/CRTC.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/154>
2021-02-15 08:42:18 +00:00
Марко Костић
1d5713ed3b Update Serbian translation 2021-02-15 08:19:09 +00:00
Anders Jonsson
23be404391 Update Swedish translation 2021-02-14 20:47:09 +00:00
Carlos Garnacho
a5db9ee2d7 backends/x11: Emulate pointer motion while the pointer is off stage
Given X11 nature, the pointer "leaves" the stage anytime it wanders into
a client window, or any other areas that are not deemed part of the
stage input region.

Yet we want to stay correct in those situations, e.g. have the clutter
side reasonably in sync, picking and highlighting to work properly, etc.

In order to achieve that, emulate motion events on XI_RawMotion. These
are as much throttled as our pointer tracking for a11y, in order to avoid
too many XIQueryPointer sync calls. This emulation only kicks in anytime
that X11 notifies us that we are not "on" the stage.

This replaces some sync_pointer() calls in GNOME Shell code that are
there just to compensate for this trait of X11, e.g. in the message tray
code.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
2021-02-14 13:23:29 +00:00
Carlos Garnacho
437f5d1c66 compositor: Sync pointer after begin/end modal on X11
Ensure we issue a motion event for the current pointer position,
as there might be situations where compositor modals get X grabs
from other clients stacked on top, or missed events in between
otherwise.

Ensure the Clutter state is still up-to-date afterwards here. This
replaces some sync_pointer() calls done in GNOME Shell code, always
done after modality changes.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
2021-02-14 13:23:29 +00:00
Carlos Garnacho
00c7f45a0f compositor: Refactor backend-specific code into MetaCompositor vfuncs
Do these Wayland operations (that apply on both native and nested backends)
in the MetaCompositorServer subclass. We want to add more backend specific
behavior here in the future.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
2021-02-14 13:23:29 +00:00
Balázs Úr
5a1e942f3b Update Hungarian translation 2021-02-14 12:46:29 +00:00
A S Alam
bcde7dcedc Update Punjabi translation 2021-02-14 05:21:53 +00:00
Philipp Kiemle
6510a70753 Update German translation 2021-02-13 21:31:55 +00:00
Michel Dänzer
91229e824e ci: Drop dependencies: stanzas
Redundant with needs:.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1725>
2021-02-10 09:52:56 +01:00
Carlos Garnacho
698fe3f1a9 wayland: Avoid automatically decoupling source/offer after grab
In the case that DnD is performed and succeeds, we want to release
the grab early, and let the transfer IPC happen in the back. For
that to happen without a hitch, drag source and offer must be left
related to each other after undoing the grab, even though the default
ungrabbing code does that automatically (indirectly, by unsetting the
drag focus).

In these cases, we used to manually unset the current source, so
this decoupling was skipped. Notably, one missed case is X11 DnD,
so we might end up with the situation there that DnD did succeed,
transfer is ongoing, but the source and offer are already decoupled,
this confused the machinery and missed the finishing XdndFinished
to be emitted to the X11 drag source.

The prior commits prepared for this source/offer decoupling being
a manual operation, this commit avoids doing this automatically
when ungrabbing.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
2021-02-09 19:33:13 +00:00
Carlos Garnacho
0f9dc84d3b wayland: Manually detach source/offer on failure paths
Adapt more paths to manual detaching of source/offer. This is still
done automatically when the grab is finished.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
2021-02-09 19:33:13 +00:00
Carlos Garnacho
8e01ea1e04 wayland: Plug XDnD drag source leak
This object is just being detached, with no code unref'ing it. Do
this whenever the XDnD selection goes unowned, usually a good
indication that the drag source no longer is one.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
2021-02-09 19:33:13 +00:00
Carlos Garnacho
3799606fc2 wayland: Make XDnD grab unlink source/offer manually
This currently happens by default whenever the grab is finished.
We want to eventually do this manually everywhere, so start here.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
2021-02-09 19:33:13 +00:00
Olivier Fourdan
3322e4fa54 surface-actor-wayland: Handle Xwayland vanishing gracefully
When a game is playing fullscreen, mutter may use a direct scanout of
the surface.

However, if that surface is from Xwayland and Xwayland had vanished (now
that mutter can survive that), the actual surface might be NULL, so
check for that case to avoid a crash.

Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/1638
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1718>
2021-02-09 19:06:22 +00:00
Olivier Fourdan
445373d028 x11: Check for XCB reply
Now that mutter can survive Xwayland vanishing in mid-flight, we need to
actually check if the Xserver reply fetched though XCB is not NULL,
otherwise we may crash, that would be a shame.

Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/1638
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1718>
2021-02-09 19:06:22 +00:00
Dor Askayo
9b8cff8673 renderer/native: Remove unnecessary field and logic
This field was never set and only ever cleared.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1715>
2021-02-09 08:27:11 +00:00
Dor Askayo
5d32b251ed renderer/native: Remove unused field
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1715>
2021-02-09 08:27:11 +00:00
Dor Askayo
80fd030f10 onscreen/native: Move function declaration to the correct header file
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1715>
2021-02-09 08:27:11 +00:00
Dor Askayo
d6abea3ba7 onscreen/native: Add missing error messages
g_set_error_literal() asserts that the provided message is not NULL.
If it is NULL, the function is entirely no-op.

This resulted in a NULL dereference of the GError, which remained
NULL in this case, when trying to print a warning in
clutter_stage_cogl_redraw_view().

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1715>
2021-02-09 08:27:11 +00:00
Dor Askayo
2c0bd98f21 connector/kms: Add missing else statement
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1715>
2021-02-09 08:27:11 +00:00