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>
This will require some symbol exporting, but the benefit is that have
better control of what external test cases can do in terms of creating
more testing specific contexts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This makes it possible to declare the type in an installed header (so
that e.g. META_CONTEXT_TEST(context) works), but without having to
expose the MetaContextClass struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Add a method meta_context_destroy() that both runs dispose and unrefs
the context. Tear down is moved to dispose() so that things owned by the
context are destroyed when calling meta_context_destroy(), or when the
last reference is released.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Before we first created the MetaWaylandCompositor instance, which would
repare Clutter/Cogl so they could initialize and turn on Wayland display
server features, then later to initialize the rest. Now that part is
done by the Wayland infrastructure itself, so we don't need the early
initialization. Simplify things a bit by centralizing it all into a
single meta_wayland_compositor_new() call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This is done by keeping around a pointer to MetaContext as
"client_pointer" (which is practically the same as "user_pointer"
elsewhere), as well as creating a `MetaIceConnection` wrapper for ICE
connections.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
As with the compositor type enum, also have the X11 display policy enum,
as it's also effectively part of the context configuration. But as with
the compositor type, move it to a header file for enums only, and since
this is a private one, create a private variant meta-enums.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Since this tests the `--virtual-monitor` command line argument, it uses
the `MetaContextMain` variant of the context, as it's there that command
line argument is handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This object intends to replace the scattered functions that are used to
make up what is effectively a "mutter context". It takes care of the
command line arguments that is now done in main.c, persistant virtual
monitors, and the like.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
The clutter tests neeed to start and stop, thus uses their own main loop
instead of the one in MetaContext. Shouldn't matter, since nothing
in mutter should happen that makes the test self-terminate from inside
mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Users can add option entries, and it'll be part of the configuration
phase.
Create the main group manually to be able to set a user_data pointer;
this will be required to not have to rely on globals when parsing
options using a callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This intends to replace the call to `meta_register_with_session()` that
deals with X11 session management, and is called when the user is
"ready". In thet test context, doing that makes no sense, so make it a
no-op.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
The start phase creates the MetaDisplay object, and initializes Wayland, and
creates the main loop.
The run phase runs the main loop and handles returning an error if the
context was terminated with an error.
The terminate phase terminates the main loop, with or without an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Configuration is the first step of the lifetime of a context, after
creation; it's here where argc/argv is processed, and it's determined
what kind of compositor, etc, it is going to be.
The tests always run as Wayand compositors, so the configuration is
quite simple, but will involve more steps later on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
It'll be part of and owned by MetaContext, intending to replace
`meta_is_wayland_compositor()`, but place it in a new file for public
enums so that it can be used from wherever.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This introduces a MetaContext implementation aimed to be used for test
cases, with as little boiler plate as possible needed in the test.
It currently doesn't do anything, just fills out the GObject boiler
plate and sets a name.
Build it into every core test, for compilation, even though it isn't
used anywhere yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This type is intended to replace the scattered functions used to
configure how the Mutter compositor is run. It currently doesn't do
anything, and only has a human readable name, intended to be set to e.g.
"GNOME Shell".
It's an abstract type, and is intended to be used via either a future
`MetaContextMain` for real display server use cases, and a
`MetaContextTest` for test cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Scanout doesn't go through the usual path of compositing and doing
eglSwapBuffers, therefore it doesn't hit the timestamp query placed in
that path. Instead, get the timings by binding the scanout buffer to an
FBO and doing a timestamp query on the FBO.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
In order to make it possible to e.g. unload an unused DRM device, we
need to make sure that we don't keep the file descriptor open if we
don't need it; otherwise we block anyone from unloading the
corresponding module.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
The DRM buffers aren't really tied to mode setting, so they shouldn't
need to have an associated mode setting device. Now that we have a
device file level object that can fill this role, port over
MetaDrmBuffer and friends away from MetaKmsDevice to MetaDeviceFile.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
Keep a private MetaDeviceFile instance for the GPU's managed by the
renderer. This is a step towards decoupling rendering from mode setting,
as well as on-demand holding of device file descriptors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
Tags are meant to make it possible for a device file opener to tag a
file if it has affected the state the file descriptor is in; e.g. if it
has enabled a DRM capability.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
Handle open() failing due to being interrupted by trying again until it
either succeeds, or fails due to some other error. This was an error
handling path taken when opening sysfs files; do the same here to not
potentially regress once we open sysfs files with the device pool.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
It's only when we take/release from/to logind we need these two
integers, so only retrieve them when that's done. Making this change
makes it possible to open devices that don't have these parameters.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
This changes the way the KMS backends load; if we're headless, we always
use the dummy one and fail otherwise; in other cases, we first try the
atomic backend, and if that fails, fall back on the simple one.
The aim for this is to have the impl device open and close the device
when needed, using the device pool directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
This practically does the same thing as part of MetaLauncher, except
with added thread safety and caching. For example, opening the same file
a second time will return the same MetaDeviceFile, and only once all
acquired MetaDeviceFile's are released, will the file descriptor be
closed and control of the device released.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
ClutterInputDevice's get_group_n_modes() vfunc is meant to return
-1 for groups that are out of the known range, not within. Fix the
early return condition, and let the native backend return correctly
the number of modes for the given group.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1920>
Scanouts are taken away after painting. However, when we're
streaming, what we actually want is to capture whatever is
going to end up on screen - and that includes the scanout
if there's any.
Add a before-paint watch that only records new frames if a
scanout is set.
Inspired by (and commit log mostly copied from) e6a13e5d57
("monitor-stream-src: Add before-paint watch to catch scanouts").
v2:
* Do not call stage_painted from before_stage_painted (Georges Basile
Stavracas Neto)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1707
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1902>
When the MetaWindow resize machinery for toplevels ended up in the
Wayland window implementation, we tried to avoid configuring
not-yet-mapped windows that just had its zero sized dimension pass
through the constraint machinery, resulting in a 1x1 sized window.
If we'd properly set up the min size metadata earlier, that 1x1 would
likely be the minimum size set of a window, which makes things harder to
predict when peeking at side effects.
However, what the side effect peeking intends to do, as documented in
the comment, was to figure out when the client hadn't committed any
buffer yet, i.e. during the initial map, and in those cases avoid
sending that nasty 1x1 size, resulting in silly window sizes. A more
robust way to detect this is instead checking when we shouldn't really
try resize things our own way, and in those cases early out as was done
before.
This means that, for a yet to me mapped window, we only ever want to
send an initial non-zero configuration when 1) it's initially maximized,
2) initially fullscreen, or 3) initially tiled in any way, as those are
the situations where the compositor is the one deciding the size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1912>
When drmModePageFlip() or drmModeAtomicCommit() unexpectedly failed (e.g.
ENOSPC, which has been seen in the wild), this failure was not handled
very gracefully. The page flip listener for the scanout was left in the
MetaKmsUpdate, meaning when the primary plane composition was later page
flipped, two page flip listeners were added, one for the primary plane,
and one for the scanout. This caused the 'page-flipped' event to be
handled twice, the second time being fatal.
Handle this by making 'no-discard' listener flag be somewhat reversed,
and say 'drop-on-error', and then drop all 'drop-on-error' listeners
when a MetaKmsUpdate failed to be processed.
Also for a "preserve" flagged update, don't ever trigger "discard"
callbacks just yet, as preserved updates are used again for the primary
plane composition, in order to not miss e.g. CRTC gamma updates, or
cursor plane updates, which were added separately.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1809
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1910>
The cancel phase for swipe gestures was not being handled, hence,
Wayland "end" events where not sent to clients when the gesture was
cancelled.
A swipe gesture is cancelled when extra finger(s) are put down on the
touchpad in the middle of the gesture or when some, but not all, of the
fingers are put up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1857>
