Makes workspace transitions in gnome-shell look more seamless, since
both outgoing and incoming workspace have focused windows.
This is only done for click focus mode, since it's not known which
window would be focused for the other modes.
Track the state and recompute it when it changes, to avoid redrawing
the windows needlessly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/850>
Each workspace has a window that will be focused when switching to that
workspace. Add a function to retrieve that window.
This is only relevant for click-to-focus focus mode, since with the two
other modes no window will be focused upon switching, and will only gain
focus when hovered.
This will be used in the next commit to make this window appear focused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/850>
This was introduced by accident in commit 1467b6b02a
y-inverted textures in combination with shape masks appear to
be only commonly used with EGLstreams. However, as we draw the
shape mask ourselves, we don't want to apply the y-invert to it
as testified by the left over `cogl_pipeline_set_layer_matrix()`.
Note that we still allow to apply viemports and buffer transforms,
as the Xwayland mode setting emulation may use it (in fact only
the former, but it probably does not hurt to leave the later as well).
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1792
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1937>
Monitor configuration check tests can be very complex and in case of
failures we can't easily catch where a failure happened without entering
in debug mode, something that isn't always an option in CI or external
builders.
So add more debug statements in configuration check functions and use
macros to ensure that we print the caller function and location on more
complex check functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Primary monitor is just the same of the other monitors, but it has a
primary monitor flag. Since the computation of the scaling isn't
dependent anymore on the computed configuration we can now generate the
primary monitor config together with the others.
However, we've to ensure that the primary monitor is the first of the
configs list in order to properly compute the positioning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Compute the monitor scaling in a separated function using the primary
monitor (not its config) and pass it to the creation function instead.
This will allow removing the special logic for the primary monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Factorize the creation of a configuration inside one function that looks for
the primary monitor and the other monitors using the matching rules and
dispose them according to the chosen policy (checking if the result is valid
when using the suggested positioning).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Add a find_monitors function that allows to search for monitors that match
the MonitorMatchRule filter and use this to look for the primary monitor and
the other monitors that need to match the requested filter in order to be
configured.
Having just one function doing this kind of checks reduces the possibility
of unexpected results.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Verify that the suggested monitor configuration contains only adjacent monitors,
and that if this is not the case we fallback to the linear configuration.
This can happen in case of multi-DPI setup, so add a test checking this too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
It could happen that monitors suggest to use coordinates that don't take
in consideration the scaling applied to one monitor, and such the
generated configuration is not valid because not all the monitors are
adjacent.
So enforce this check before accepting a suggested configuration as it
is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
We may need to check if rectangles region has adjacent neighbors and
so if there are no gaps in between monitors.
This can be done by checking if each monitor is adjacent to any other in
the same region.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
This code sneaked unconditionally, even though we can disable
tracing code with -Dprofiler=false. Add some COGL_HAS_TRACING
checks so that this code is also optionally built.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1951>
This code sneaked unconditionally, even though we can disable
tracing code with -Dprofiler=false. Add some COGL_HAS_TRACING
checks so that this code is also optionally built.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1951>
When a selection owner advertises a mime type, but does not provide the
content upon a request for the mime type content, the requesting side
might wait indefinitely on the content.
To avoid this situation, add a timeout source, which will cancel the
selection transfer request after a certain timeout (15 seconds) passed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1874>
Currently, if g-r-d closes the read end of the pipe for a
SelectionRead() operation, due to realizing that the application, that
should provide the mime type content, does not provide any content,
mutter won't notice that and still assumes that the read() operation
on the pipe in g-r-d is still happening, as mutter never writes to the
pipe in that situation and therefore cannot realize that the pipe is
already closed.
The effect of this is, that if g-r-d aborts a read() operation and
requests a new read() operation via SelectionRead(), mutter will deny
the request since it assumes that the previous read() operation is
still ongoing.
Fix this behaviour by also checking the pipe fd in mutter before
denying a SelectionRead() request.
https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/60
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1874>
With some resolutions (such as 4096x2160) we may compute duplicated
scale factors because we used a too wide threshold to check for an
applicable value.
In fact, while when we're at the first and last values it's fine to
search applicable values up to SCALE_FACTORS_STEP, on intermediate ones
we should stop in the middle of it, or we're end up overlapping the
previous scaling value domain.
In the said example in fact we were returning 2.666667 both when
looking to a scaling value close to 2.75 and 3.00 as the upper bound of
2.75 (3.0) was overlapping with the lower bound of 3.0 (2.75).
With the current code, the lower and upper bounds will be instead 2.875.
Adapt test to this, and this allows to also ensure that we're always
returning a sorted and unique list of scales (which is useful as also
g-c-c can ensure that this is true).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1878>
We introduced META_MONITOR_SCALES_CONSTRAINT_NO_FRAC to get global scale
values however, this didn't work properly for some resolutions.
In fact it may happen that for some resolutions (such as 3200x1800) that
we did not compute some odd scaling levels (such as 3.0) but instead
its closest fractional value that allowed to get an integer resolution
(2.98507452 in this case).
Now this is something relevant when using fractional scaling because we
want to ensure that the returned value, when multiplied to the scaled
sizes, will produce an integer resolution, but it's not in global scale
mode where we don't use a scaled framebuffer.
So, take a short path when using no fractional mode and just return all
the applicable values without waste iterations on fractional values.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1878>
Scaling values computation code served us well in the past years but
it's quite delicate and it has some issues in edge cases, so add a test
that verifies that the computed scaling values for all the most common
resolutions (and some that may be common in future) are what we expect
to be.
This may also serve us in future when we'd define a better algorithm to
compute the preferred scale, but this not the day.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1878>
When deriving the global scale from current monitor, we were just checking the
supported value by the primary monitor, without considering weather the current
scale was supported by other monitors.
Resolve this by checking if the picked global scale is valid for all active
monitors, and if it's not the case, use a fallback strategy by just picking the
maximum scale level supported by every head.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/407
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/336>
In Xrandr we were caching the available scaling modes that were computed just
for the current mode, for each monitor, while we can actually reuse the
default implementation, by just passing the proper scaling constraint.
In monitor we need then to properly filter these values, by only accepting
integer scaling factors that would allow to have a minimal logical monitor
size.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/407
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/336>
