Commit Graph

28201 Commits

Author SHA1 Message Date
Jonas Dreßler
b770ea606a background-content: Optimize rounded clipping shader a bit
We're using the gtk4 shader for rounded rect clipping here, and gtk just
introduced a small optimization to make this shader a bit faster, so
let's do the same.

See 57e354c297

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1774>
2021-03-11 22:59:07 +01:00
Marco Trevisan (Treviño)
244e881912 backends/input-settings: Do not disconnect seat signals
This was added with commit c956193d, when we did connect to the seat
signals in input settings, but this is not the case anymore since commit
2c1558dd, so we can safely remove this call now.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1763>
2021-03-10 16:18:25 +00:00
Marco Trevisan (Treviño)
8d008112b6 backends/x11: Pass the seat to the input settings
Input settings requires a valid seat in order to initialize the a11y
settings (since commit 1609d145), however in X11 we never set it and
even if we create the input settings early (as per commit 7547891a) we
never initialize the seat for it.

This leads to startup critical errors on X11:
 clutter_seat_get_pointer_a11y_settings: assertion
   'CLUTTER_IS_SEAT (seat)' failed

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1763>
2021-03-10 16:18:24 +00:00
Suryashankar Das
b353b97512 backends/x11: Fix device hierarchy event handling for x11 backend
This commit adds the events created in the function
`meta_seat_x11_notify_devices` to the clutter events queue, which
are currently only added to the stage queue making the events not
being picked up by the `clutter_seat_handle_event_post` function.
This results in devices not getting added to the device-list of
`MetaInputSettings`.

Fixes the bug in which mouse and touchpad settings are not working in
the settings app during x11 session.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1767>
2021-03-10 15:44:46 +01:00
Marco Trevisan (Treviño)
012c0a18ef clutter: Ensure we always call handle_event_post for processed events
Since commit 2ceac4a device-related X11 events aren't processed anymore,
causing the input settings not to handle the devices.
This is due to the fact that we may never call clutter_seat_handle_event_post()
for such events.

While this is always happening for the native backend, it doesn't happen in
X11 because the events are removed from the queue as part of
meta_x11_handle_event(), and thus no event was queued to the stage by the
backend events source.

This also makes sure that the event post handler is called after the
event is actually processed, and not before an event is queued.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1564
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
2021-03-10 13:56:54 +00:00
Marco Trevisan (Treviño)
ccbdf91776 backends/x11: Add dummy input-settings implementation
The nested backend may need to have an input setting implementation,
while we don't want to change the host settings (re-using an X11 input
settings) we can add a dummy implementation, until something more
complex is needed.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
2021-03-10 13:56:54 +00:00
Fabio Tomat
393be6c676 Update Friulian translation 2021-03-10 13:03:01 +00:00
Ivan Molodetskikh
acbaccd5c9 README: Fix list paragraphs
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1770>
2021-03-10 09:01:50 +03:00
Jonas Ådahl
dcbd96df38 README: Clarify how to name flag types
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1765>
2021-03-09 20:52:16 +00:00
Jordi Mas
86435d88a2 Update Catalan translation 2021-03-09 20:22:02 +01:00
Jonas Ådahl
9b90b5a1b0 window-actor/x11: Queue full actor redraw when redraw queued
With frame timings, we might end up in a situation where a frame drawn
is expected, but no damage was posted. Up until now, mutter handled
this, if the window wasn't completely hidden, by posting a 1x1 pixel
damage region. The problem with this is that we now are a bit more
aggressive optimizing away no-op redraws, meaning we still might end up
not drawing, making things get stuck.

Fix this by doing a full actor redraw, as that is the only reliable way
to both a new frame being drawn, as well as the actor in question itself
getting redrawn.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3369
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1471
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1754>
2021-03-09 17:42:58 +00:00
Jonas Ådahl
44a4e61665 compositor/x11: Notify the sync ring about frames on updates
The sync ring has an API about "frames", where it is notified about
the end of frames. However, its "insert wait" call is done before
updates, meaning that some "insert waits" will never see the "after
frame" if there was no frame drawn. This will cause mismatching in the
frame counting, causing freezes in the synchronization until something
else triggers an actual frame, effectively "unfreezing" the sync ring.

Fix this by not only notifying the sync ring about frames when there
were actual frames drawn, but also on plain updates which didn't result
in a drawn frame.

Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1754>
2021-03-09 17:42:58 +00:00
Sebastian Keller
c2968c89fe frame: Fix crash when clicking below titlebar with broken gtk themes
When a gtk theme uses larger shadows for the unfocused state than for
the focused one, this can cause a crash in meta_frame_left_click_event.
Since whether to call meta_frame_left_click_event is decided based on
the decoration size before focusing and the control that was clicked on
after focusing, this can result in an event handled in
meta_frame_left_click_event being on the client area.

Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1668

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1748>
2021-03-08 21:16:09 +00:00
Jonas Dreßler
3263084bcf backends/native: Translate right coords when creating motion events
With commit 7d78768809 we switched to
storing pointer coordinates in MetaInputDeviceNative instead of
ClutterInputDevice, and while we had set the coordinates of the
ClutterInputDevice in ClutterStage when queueing an event, we now set
the MetaInputDeviceNative coordinates in new_absolute_motion_event().

Here a small mistake snuck in: new_absolute_motion_event() only
translates the coordinates of the event, but we call
meta_input_device_native_set_coords() using the x and y variables
(which remain untranslated), so now the input device coordinates are no
longer translated.

Fix that by translating the coordinates of the x and y variables in case
we're we handling a tablet/stylus event instead of only translating the
event coordinates.

Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1685

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1760>
2021-03-08 15:33:36 +00:00
Jonas Ådahl
ec14f51ae3 cogl/onscreen/egl: Remove platform pointer
It's not used anymore, so remove it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1759>
2021-03-08 15:02:30 +00:00
Jonas Ådahl
b962822f26 onscreen/native: Fix cast from CoglOnscreenEgl
It used the defunct platform pointer, meaning if this path would have
hit, it'd end up with a segmentation fault due to the platform pointer
being NULL.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1759>
2021-03-08 15:02:30 +00:00
Jonas Ådahl
372737e282 tests/clutter/timeline-interpolate: Use correct clock
This fixes the interpolate test to not use the wall clock, but the
monotonic clock. It also cleans up the timestamp granularity naming, so
that the different granularity is clearer, as in the test, different
timestamps have different granularity.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
2021-03-08 14:37:00 +00:00
Jonas Ådahl
6f30764320 tests/clutter/timeline-interpolate: Rework test to be less flaky
This more or less rewrites this test so that it explicitly tests the
"interpolation" when a timeline loops, i.e. that if something occupies
the thread when a timeline was supposed to have looped, we end up in the
right place "in the middle" of the next timeline cycle.

The test more or less does this:

 * Start a 3 second looping timeline
 * Sleep so that we're in the middle of the first cycle
 * Sleep again so that we end up in the middle of the next cycle

The semantics checked are that we see the following frames:

 * The first frame with timestamp 0
 * The second frame in the middle of the first cycle (timestamp ~= 1.5
   sceonds)
 * The third frame in the end of the first cycle (timestamp == 3.0
   seconds)
 * The fourth frame, first in the second cycle, with timestamp ~= 1.5
   seconds)

This means we can increase the "grace period" to the double (from 0.5 s
to 1 s), while at the same time decrease the time spent running the test
(from 10 s to 4.5 s). This should hopefully make the test less flaky,
especially in slower runners, e.g. aarch64.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
2021-03-08 14:37:00 +00:00
Jonas Ådahl
0d3840b056 tests/clutter/timeline-interpolate: Assorted style cleanups
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
2021-03-08 14:37:00 +00:00
Jonas Ådahl
b155063227 tests/test-client: Set padding to 0 too
This makes size dependent stacking tests less flaky.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
2021-03-08 14:37:00 +00:00
Jonas Dreßler
301198a9b8 Revert "backends: Use also a native cursor renderer for tablets"
With commit c985753442 the support for
multiple hardware cursors broke, but those were never properly supported
anyway as we usually assume there's only one hardware cursor around.

With the introduction of the KMS thread in the future, we'll only have
one KMS cursor that gets updated directly from the input thread. So
apart from the fact that it never really makes sense to have two cursors
visible, in this new model having multiple cursors won't work anyway.

So make the cursor we show for stylii a software cursor again.
Eventually the plan is to make the input device that's driving the KMS
cursor interchangeable, so that we can always use hardware cursors.

This reverts commit 165b7369c8.

Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1645

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1758>
2021-03-08 13:13:22 +00:00
Jonas Ådahl
393a85971c clutter/stage-view: Disable double buffered shadow buffering
To make the double buffered shadow buffer damaged tiles detection
feasable, a new EGL extension is needed for creating FBO's backed by
a custom CPU memory buffer, instead of DMA buffers, as DMA buffers can
be very slow to read, much slower than just painting the shadow buffer
directly.

Leave the code there, since such an EGL extension is intended to be
added, but hide it behind an env var so that it isn't enabled by
accident.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1724>
2021-03-08 11:11:01 +00:00
Ivan Molodetskikh
82af1fb87e wayland: Send presentation feedbacks to cursors
This commit assumes that cursor surfaces work in a "mailbox" fashion. If
they are painted multiple times before a successful flip, all commits
but the last get discarded, and the last commit gets presented after the
flip succeeds. This is more or less how it works in the atomic backend,
and also more or less how it works in other backends, with the exception
that the cursor painting might fail without any way of knowing. This
assumption is still better than unconditionally discarding all cursor
surface feedbacks as if the cursor painting always fails.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:12 +00:00
Ivan Molodetskikh
cd9ae13465 backend: Pass stage view to cursor-painted signal
Will be used for presentation-time handling.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:12 +00:00
Ivan Molodetskikh
2ce3a050f0 wayland: Wire up presentation-time machinery
- add surfaces to the presentation list,
- move their feedbacks to the map in on-after-update,
- fire the feedbacks in on_presented().

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:12 +00:00
Ivan Molodetskikh
f0c2200466 wayland: Store map of ready presentation feedbacks
These are feedbacks for updates that were drawn or otherwise displayed
on screen, and need to be fired as soon as their presentation happens.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:12 +00:00
Ivan Molodetskikh
0c3490223e wayland: Store list of presentation-time surfaces
These are surfaces that might have registered presentation-time
callbacks, similar to the frame callback surface list.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:12 +00:00
Ivan Molodetskikh
bb57f35296 wayland: Add presentation_feedback_present()
Regarding the sequence = 0 fallback: in some cases (moving a cursor
plane on atomic amdgpu) we get sequence = 0 in the page flip callback.
This seems like an amdgpu bug, so work around it by assuming a sequence
delta of 1 (it is equal to 1 because of the sequence != 0 check above).

Sequence can also legitimately be 0 if we're lucky during the 32-bit
overflow, in which case assuming a delta of 1 will give more or less
reasonable values on this and next presentation, after which it'll be
back to normal.

Sequence is also 0 on mode set fallback and when running nested, in
which case assuming a delta of 1 every frame is the best we can do.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
dccc60ec3e wayland: Implement stub presentation-time
The presentation-time protocol allows surfaces to get accurate
timestamps of when their contents were shown on screen.

This commit implements a stub version of the protocol which correctly
discards all presentation feedback objects (as if the surface contents
are never shown on screen). Subsequent commits will implement sending
the presented events to surfaces shown on screen.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
2f4027200f Generate presentation-time files
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
f02f17808a onscreen/native: Send a symbolic flip on discard
Now that symbolic flips were introduced, it makes more sense to use them
instead of emitting a fake page flip.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
02d7fca716 clutter/frame-info: Add VSYNC flag
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
47183a94eb cogl/frame-info: Add VSYNC flag
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
93ef83a96c clutter/frame-info: Add ZERO_COPY flag
Will be used in the presentation-time Wayland protocol.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
9123aa4e84 cogl/frame-info: Add ZERO_COPY flag
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
99efb40cce clutter/frame-info: Add sequence
It will be used for the presentation-time Wayland protocol.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
c96fb181ab cogl/frame-info: Add sequence
It will be used for the presentation-time Wayland protocol.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
5d8cb2786b cogl: Remove get_monotonic_time_ns()
It's no longer needed. Everything else uses and assumes
g_get_monotonic_time().

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
4ba2df0bd2 cogl: Remove cogl_get_clock_time()
It's no longer used.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
4810164885 cogl: Make presentation time always MONOTONIC
This concerns only the cases when the presentation timestamp is received
directly from the device (from KMS or from GLX). In the majority of
cases this timestamp is already MONOTONIC. When it isn't, after this
commit, the current value of the MONOTONIC clock is sampled instead.

The alternative is to store the clock id alongside the timestamp, with
possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from
GLX; this might be the same as REALTIME, I'm not sure), and then
"convert" the timestamp to MONOTONIC when needed. An example of such a
conversion was done in compositor.c (removed in this commit). It would
also be needed for the presentation-time Wayland protocol. However, it
seems that the vast majority of up-to-date systems are using MONOTONIC
anyway, making this effort not justified.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:11 +00:00
Ivan Molodetskikh
d8606829c4 cogl: Report presentation time in microseconds
KMS and GLX device timestamps have microsecond precision, and whenever
we sample the time ourselves it's not the real presentation time anyway,
so nanosecond precision for that case is unnecessary.

The presentation timestamp in ClutterFrameInfo is in microseconds, too,
so this commit makes them have the same precision.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:10 +00:00
Ivan Molodetskikh
9f53b691c4 clutter/frame-info: Add HW_CLOCK flag
A flag indicating whether the presentation timestamp was provided by
the display hardware (rather than sampled in user space).

It will be used for the presentation-time Wayland protocol.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:10 +00:00
Ivan Molodetskikh
9d54ef3994 cogl/frame-info: Add HW_CLOCK flag
A flag indicating whether the presentation timestamp was provided by the
display hardware (rather than sampled in user space).

It will be used for the presentation-time Wayland protocol.

This is definitely the case for page_flip_handler(), and I'm assuming
this is also the case for the two instances in the GLX code.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-03-08 09:48:10 +00:00
Hugo Carvalho
d54dc1ae7c Update Portuguese translation 2021-03-07 15:26:47 +00:00
Piotr Drąg
3991fc99fb Update Polish translation 2021-03-07 14:00:06 +01:00
Claude Paroz
903a30d94b Updated French translation 2021-03-06 10:35:14 +01:00
Jonas Dreßler
ef1f65a013 clutter/text: Emit cursor-changed right after setting cursor position
ClutterText has a bit of a mess around its signalling of changes to the
cursor position: There's the position (deprecated) and cursor-position
property, and  there's the cursor-changed and cursor-event (deprecated)
signal. The two properties are supposed to be notified when the cursor
position changes, and the two signals are notified when the cursor
position or size changes.

Now the properties notifications and the signals get fired in two very
different places: The two properties are notified in
clutter_text_set_cursor_position(), while the signals are fired during
the paint cycle when we figured out the final cursor position. The
latter is a pretty bad idea, nobody expects such a signal to be fired
during painting, and also changes to the text that are done in the
signal handler will only be applied on the next paint.

Now StEntry listens to cursor position changes via cursor-changed and
invalidates its text shadow, but since the signal is only notified
during the paint, the old text shadow will still get applied. To fix
this, also emit the cursor-changed signal when we notify the
cursor-position property.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1757>
2021-03-05 18:58:44 +00:00
Akihiko Odaki
a6df6796dd backend/native: Add tests for refresh rate calculation
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1737>
2021-03-05 14:37:48 +00:00
Akihiko Odaki
a41c30338f backend/native: Calculate refresh rate in double-precision
The old calculation was introduced to improve the precision
with commit c16a5ec1cf.

Here, I call the calculation as "revision 2", and the
calculation even older as "revision 1", and the new
calculation introduced with this commit as "reivion 3".

Revision 2 has two problems:
1. The calculation is mixed with fixed-point numbers and
   floating-point numbers.

To overcome the precision loss of fixed-point numbers division,
it first "calculates refresh rate in milliHz first for extra
precision", but this requires converting the value back to Hz.
An extra calculation has performance and precision costs.
It is also hard to understand for programmers.

2. The calculation has a bias.

In the process, it does:
refresh += (drm_mode->vtotal / 2);
It prevents the value from being rounded to a smaller value in
a fixed-point integer arithmetics, but it only adds a small
bias (0.0005) and consumes some fraction bits for
floating point arithmetic.

Revision 3, introduced with this commit always uses
double-precision floating-point values for true precision and
to ease understanding of this code. It also removes the bias.

Another change is that it now has two internal values, numerator
and denominator. Revision 1 also calculated those two values
first, and later performed a division with them, which minimizes
the precision loss caused by divisions. This method has risks of
overflowing the two values and revision 1 caused problems due to
that, but revision 3 won't thanks to double-precision. Therefore,
revision 3 will theoretically have the result identical with
the calculation with infinite-precision.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1737>
2021-03-05 14:37:48 +00:00
Jonas Dreßler
504af40c69 window: Don't stop irrelevant TOUCH_END events during window grab ops
During window grab ops we only react to touch events that have the
pointer emulating sequence, all other events should be propagated.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/427>
2021-03-04 22:46:20 +00:00