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>
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>
