In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
The device/sequence may not currently have a set of coordinates to return.
We correctly leave the out values uninitialized, but don't tell the upper
layers in any way.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3183>
We have a mechanism to trigger repick after animations on
clutter_actor_set_final_state(), but this will not happen if
animations are disabled.
In this case, shell transitions and other typically animatable
changes on the transform of actors will not naturally trigger
a pointer repick when those get instantly changed to the final
state, possibly preserving the cached state and missing the
just popped in actor altogether.
Trigger an instant repick on animation-less transform changes,
so that these situations are also handled correctly, and the
pointer drops the cached state and is able to find the new
actor.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2918
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3168>
The clutter_seat_handle_event_post() function wants to handle
CLUTTER_DEVICE_ADDED/REMOVED to perform signal emission, but
checks (and asserts) that every event going through it has a
source device.
This is no longer quite true for IM events (they are attached
to the ClutterSeat's keyboard, not a HW device), so the assert
can now fire off (of course undesiredly).
But anyways, for events built through
clutter_event_device_notification_new() (the ones this function
is interested in, after all), it is already a precondition check
that the device is proper at the time of creating the event, so
asserting for it here is redundant.
We can drop this overly generic assert, this is already ensured
for the events that matter, anyways.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3167>
With the ClutterEvent subtype structs sealed, this remains the only useful
struct type that is now usable on the Javascript side. Make all
ClutterActorClass event vmethods use ClutterEvent, and update all users
to this change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3163>
All ClutterEvent users have been changed to use getter methods
instead of direct field access. We may now make the ClutterEvent
union/structs entirely opaque by moving the definitions out of
public headers.
All future usage of ClutterEvent data should be done through
getter methods.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Move the string construction bits in the event logging happening in
MetaSeatImpl to a clutter_event_describe() call, so that it has more
freedom in fiddling with ClutterEvent internals, and may be potentially
reused in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Add methods, and change the API of some rarely used methods, in order
to make all event info currently held/necessary accessible through
ClutterEvent getters, instead of direct field access.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
The full decomposed modifier state is pretty much unused, relying
in keymap signals/properties to track latched modifiers state instead.
The events can be simplified without having this information, and if
it were ever needed in the future, it would be nicer that it had a
dedicated struct and didn't increase the number of arguments in
ClutterEvent constructors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
We need to change at least event flags in the event we reinject after
it was let through by the IM, in order to avoid doubly handling.
Create a full event copy from the original event parameters.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Avoid peeking in the stage for loosely related actors, since the same
event could be handled by different actors across the picking stack.
This getter is also unused, so there's wiggle room here for changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
These constructors take all the necessary arguments to build the
event from the get go, so the callers are not left up with the task
of setting up the event struct data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Despite the attempt to make this a generic interface, this was
pretty much used only by the X11 backend, and now it ported away
from it.
This now stands unused and may be removed, in favor of backends
each creating and injecting events as they please.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
It is a bit backwards that events contain information about
the stage they are being handled by. It makes more sense to
specify in the ClutterEvent handling entrypoint the stage
that will handle the event.
As a first step, add this ClutterStage argument, even though
the information is still carried through the event in order to
keep satisfying calls to the getter function.
This entrypoint has been also renamed to clutter_stage_handle_event(),
so that its ownership/namespace is clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Measurements above 100% were originally allowed to show when frame skipping
was occurring so you didn't have to also check the frame rate. But that
also resulted in arbitrarily high jitter values being reported when
returning from idle. And those are frequent enough to look like a bug or
untrustworthy so let's not do that anymore.
Taking the remainder of a high jitter value is still a meaningful jitter
value.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2906
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3123>
clutter_frame_clock_compute_max_render_time_us clamps to the refresh
interval anyway, so the only effect a higher recorded maximum can have
is to delay it falling below the refresh interval again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3090>
Instead of separate pairs of short- and long-term maxima for each
measured step of the frame update process.
This should result in the render time estimate rising less often:
Previously it did whenever the measurement of any of at least 3 out of
4 steps reached a new maximum, even if that didn't result in a new
maximum for the whole update duration. Now it's only in the latter
case.
This should also result in a lower render time estimate (and thus
input→output latency) in general, since the variability of
measurements for each 3/4 steps doesn't always add up anymore. The flip
side of this is that it might result in missing a display refresh cycle
more often.
v2:
* Fix coding style in maybe_update_longterm_max_duration_us.
(Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3090>
This adds some plumbing to get the "default" paint flags for regular
stage painting, where one either wants to paint the overlay, or not.
If inhibited, the 'no-cursors' paint flag is used, otherwise the 'none'
flag. This will be used to allow having a per stage view hw cursor
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
When a relative pointer motion gets constrained (e.g. a monitor edge or
barrier), save the constrained relative motion delta too.
This will later be used to send the remaining motion delta to input
capture clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
