This is a signal that will be emitted between the 'before-update' and
'before-paint'. It can be used to handle things when you know whether
there is an update, and you know whether a paint or not will happen, by
looking at the current damage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
This handle is used by the legacy KMS API; lets avoid having to have GBM
specific code where this is done by letting the MetaDrmBuffer API, that
already has this information, expose it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
We'd put the message in a variable called `message`. If something passed
to meta_topic() was called `message`, it'd end up being `NULL` in the
log entry. Avoid this by making the local message variable a bit more
"on topic".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
Mutters event filter can prevent events from getting processed by
Clutter, this can also happen for TOUCH_END/CANCEL events. Processing
these events in Clutter is crucial for proper tracking of touch
sequences though, that's because Clutter adds a PointerDeviceEntry to
the stage on a TOUCH_BEGIN *before* going through the event filter, but
removes that entry on a TOUCH_END *after* going through the filter. So
Clutter really needs to see those TOUCH_END events, or else there will
be a stale PointerDeviceEntry on the ClutterStage.
Make sure those TOUCH_END/CANCEL events always get seen by Clutter by
removing the device entry immediately when those get filtered out.
Because there might still be events belonging to this sequence in the
event queue of the stage, we need to flush the queue before removing the
entry, too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2350>
Unfortunately we cannot do this generically since the target of the
button/touch press does matter, e.g. tapping on the OSK, or clicking
the IBus candidates window. These situations should not trigger a
reset.
So be more selective about the situations where button/touch presses
trigger an IM reset, in the case of ClutterText these are still clicks
inside the actor, for Wayland's text-input it is when clicking the
surface that has text_input focus.
For all other situations where clicking anywhere else might make
sense to trigger an IM reset are covered by the focus changing paths,
that also ensure a reset before changing focus between surfaces/actors.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1961
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Focus changes should trigger an IM reset, as some engines do want
to maybe commit the preedit string before changing focus. In addition,
we do not want the preedit string to be able to move between
windows/applications.
Ensure that the commit string is committed when the IM deems so, and
ensure we send a .done event disntinct to the .leave event, so that
the client doesn't miss the commit.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2030
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Focus changes should trigger an IM reset, as some engines do want
to maybe commit the preedit buffer before changing focus. Since
the preedit string is also cleared on reset(), we can do without
that explicit call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Right now we have a bit of a mixed bag between an active model where
input foci set the surrounding text without being asked for (e.g.
wayland's text_input), and a passive model where the IM engines ask
for content.
Make ClutterText take the same side than text_input, so that dealing
with those is at least consistent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
The clutter_text_delete_text() function used underneath expects character
offsets for both start/end position. Fix the end position passed an offset
instead of that, and compesnate for the cursor position being always -1
when the caret is at the end of the string.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
I've overseen quite an important case in commit
98a5cb37d9: Repicking only when actors get
destroyed is not enough, we actually need to repick when actors go
hidden/unmapped.
While we could also listen to notify::mapped just like we listen to
notify::reactive, it seems better to avoid using property notifications
here due to the usage of g_object_freeze/thaw_notify() in ClutterActor.
It can lead to the stage receiving a notify::mapped with mapped = true
for a pointer actor, which really shouldn't happen (just like
notify::reactive with reactive = true shouldn't happen).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5124
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2333>
DMA buffers might be allocatable, but it doesn't mean the driver doesn't
fail when we try to allocate a buffer with an implicit modifier. Using
the proprietary NVIDIA driver for example, it will fail. Lets catch this
up front and avoid advertising DMA buffer support when we know it won't
work.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2383>
As of currently, we only emit .done() on actual changes coming from the
ClutterInputMethod/ClutterInputFocus. With the recent changes in the
interpretation of serials, it becomes more important now that the
compositor acknowledges every .commit done by the client, in order to
keep them feeding future IM state updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
Compensate the protocol statelessness with our ClutterInputFocus
statefulness. This becomes more necessary now, since sending
consecutive .done() events is now considered acceptable behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
MetaCursorRendererNative only updates the cursor state when the
underlying texture changes. The cursor scale and transform do not
trigger updates. This results in wrong cursor orientations on rotated
displays. Use both texture changes and scale and transformation changes
to figure out when to update the cursor state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2363>
We want all pointer events to be passed through the pointer a11y
processing before going through event filters: Once we go through event
filters, events might be dispatched to Wayland and get filtered out.
With the changes to immediately dispatch events to wayland, this changed
and the pointer a11y is now no longer seeing any events going to wayland
clients. Fix it by shuffling things around a bit and letting pointer
a11y take a peek at events earlier.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5192
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2332>
There's a bunch of crashes right now where the assertions in
clutter_actor_set_mapped() after calling the map/unmap() vfuncs are
failing. The only way this can happen is by re-entering
clutter_actor_set_mapped() during the map/unmap recursion.
The reason for those crashes is that the shell hides/shows some actors
in response to crossing events and key-focus changes. These in turn get
triggered by the newly introduced ungrabbing of ClutterGrabs when an
actor gets unmapped, which triggers GRAB_NOTIFY crossing events and
key-focus changes.
Since these situations are hardly avoidable (it's a valid use-case to
hide/show something in response to a crossing/key-focus event), catch
the set_mapped() call early while we reenter the mapping machinery and
log a warning instead of crashing.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3165
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2299>
With the introduction of untrottled event delivery to wayland clients,
we moved the _clutter_event_process_filters() call outside of
_clutter_process_event(). This also moved the processing of event
filters outside of the timespan where the event is added to Clutters
current_event stack, making Clutter.get_current_event() no longer
available to anything happening inside mutters event filter.
One thing that happens in mutters event filter is detecting and
triggering keybindings like the alt-tab switcher. Now the alt-tab
switcher has a special case where it finishes and activates a window
right when the keybinding gets activated, relying on the current event
time as the timestamp to activate the window.
Now since the current event time is no longer available from inside
mutters event filter, we'd pass 0 to meta_window_activate(), causing
mutter to send a notification instead of actually activating the window.
To fix this, also set a current_event for the ClutterContext when going
through event filters, this makes sure Clutter.get_current_event_time()
works when called inside keybinding handlers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2327>
When switching between the existence and not of a stage ClutterGrab, we
would correctly attempt to synchronize key focus from the perspective of
the Wayland clients.
But this synchronization should do its own checks about existing stage
grabs before determining a client window has key focus or not.
Add that check, so that grabs correctly unfocus the keyboard in Wayland
clients, in addition to pointers and touch.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2194
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2366>
When we get passed a "snippet" to the shaped texture, it's added as a
pipeline layer snippet to change how the source texture is sampled. When
we draw from a texture tower however we have allocated regular textures
which doesn't need any special layer snippet, so create separate
pipelines for those that doesn't use that snippet.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2278>
