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>
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>
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>
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>
This object takes over the functionality of meta-idle-monitor-dbus.c,
meta-idle-monitor.c and meta-backend.c, all related to higher level
management of idle watches etc.
The idle D-Bus API is changed to be initialized by the backend instead
of MetaDisplay, as it's more of a backend functionality than what
MetaDisplay usually deals with.
It also takes over the work of implementing "core" idle monitors. The
singleton API is replaced with thin wrapper functions on the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1859>
The new RecordVirtual API creates a virtual monitor, i.e. a region of
the stage that isn't backed by real monitor hardware. It's intended to
be used by e.g. network screens on active sessions, virtual remote
desktop screens when running headless, and scenarios like that.
A major difference between the current Record* API's is that
RecordVirtual relies on PipeWire itself to negotiate the refresh rate
and size, as it can't rely on any existing monitor, for those details.
This also means that the virtual monitor is not created until the stream
negotiation has finished and a virtual monitor resolution has been
determined.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Virtual monitors are monitors that isn't backed by any monitor like
hardware. It would typically be backed by e.g. a remote desktop service,
or a network display.
It is currently only supported by the native backend, and whether the
X11 backend will ever see virtual monitors is an open question. This
rest of this commit message describes how it works under the native
backend.
Each virutal monitor consists of virtualized mode setting components:
* A virtual CRTC mode (MetaCrtcModeVirtual)
* A virtual CRTC (MetaCrtcVirtual)
* A virtual connector (MetaOutputVirtual)
In difference to the corresponding mode setting objects that represents
KMS objects, the virtual ones isn't directly tied to a MetaGpu, other
than the CoglFramebuffer being part of the GPU context of the primary
GPU, which is the case for all monitors no matter what GPU they are
connected to. Part of the reason for this is that a MetaGpu in practice
represents a mode setting device, and its CRTCs and outputs, are all
backed by real mode setting objects, while a virtual monitor is only
backed by a framebuffer that is tied to the primary GPU. Maybe this will
be reevaluated in the future, but since a virtual monitor is not tied to
any GPU currently, so is the case for the virtual mode setting objects.
The native rendering backend, including the cursor renderer, is adapted
to handle the situation where a CRTC does not have a GPU associated with
it; this in practice means that it e.g. will not try to upload HW cursor
buffers when the cursor is only on a virtual monitor. The same applies
to the native renderer, which is made to avoid creating
MetaOnscreenNative for views that are backed by virtual CRTCs, as well
as to avoid trying to mode set on such views.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to
attempt to create a libinput context. This is intended to be used when
mutter is to run headless, as in without any input devices other than
virtual ones.
Currently not hooked up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
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>
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>
To get meta-renderer-native.c down to a bit more managable size, and to
isolate "onscreen" functionality from other (at least partly), move out
the things related to CoglOnscreen to meta-onscreen-native.[ch].
A couple of structs are moved to a new shared header file, as
abstracting those types (e.g. (primary, secondary) render devices) will
be dealt with later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
This adds a MetaKmsImplDevice backend using atomic drmMode* API in constrast to
non-atomic legacy drmMode* API used in MetaKmsImplDeviceSimple.
This has various behavioral differences worth noting, compared to the
simple backend:
* We can only commit once per CRTC per page flip.
This means that we can only update the cursor plane once. If a primary
plane composition missed a dead line, we cannot commit only a cursor
update that would be presented earlier.
* Partial success is not possible with the atomic backend.
Cursor planes may fail with the simple backend. This is not the case
with the atomic backend. This will instead later be handled using API
specific to the atomic backend, that will effectively translate into
TEST_ONLY commits.
For testing and debugging purposes, the environment variable
MUTTER_DEBUG_ENABLE_ATOMIC_KMS can be set to either 1 or 0 to
force-enable or force-disable atomic mode setting. Setting it to some
other value will cause mutter to abort().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/548
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This commit consolidates DRM buffer management to the MetaDrmBuffer
types, where the base type handles the common functionality (such as
managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types
their corresponding type specific behavior.
This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c
to meta-drm-buffer.c; dumb buffer allocation/management from
meta-renderer-native.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This contains a copy of a drmModeModeInfo, describing a mode. It also
has an unused pointer to the impl device it is associated with. It'll
later be used to get a blob ID for the mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Move most of the functional bits (those meant to run on a standalone
thread) to a MetaSeatImpl object. This object is managed by the MetaSeatImpl
and not exposed outside the friend MetaSeatNative/MetaInputDeviceNative/
MetaInputSettings classes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Mutter itself is versioned now, so passing the version information
to the plugin is redunant now: The version is already determined by
linking to a particular API version (gnome-shell) or by installing
to a versioned plugin path (external plugins).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1473
This is essentially a revert of
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/326. This commit
had the unintended side effect that the built sources are actually
rebuilt for every individual user of libmutter_dep. With there being more
tests and generated files, the number of targets to build is increasing
squarely.
Not doing this reduces the number of targets from 2044 to 874, thus
saving man hours and CI burnt cycles in the long run. There's the slight
risk of reintroducing the random build breaks, but mutter is essentially
doing as suggested at https://github.com/mesonbuild/meson/issues/1084
(the only difference being addressed in the previous commit), so meson
ought to behave as expected.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1458
Allowing code from inside mutter to create a child process and
delegate on it some of its tasks is something very useful. This can
be done easily with the g_subprocess and g_subprocess_launcher classes
already available in GLib and GObject.
Unfortunately, although the child process can be a graphical program,
currently it is not possible for the inner code to identify the
windows created by the child in a secure manner (this is: being able
to ensure that a malicious program won't be able to trick the inner
code into thinking it is a child process launched by it).
Under X11 this is not a problem because any program has full control
over their windows, but under Wayland it is a different story: a
program can't neither force their window to be kept at the top (like a
docker program does) or at the bottom (like a program for desktop icons
does), nor hide it from the list of windows. This means that it is not
possible for a "classic", non-priviledged program, to fulfill these
tasks, and it can be done only from code inside mutter (like a
gnome-shell extension).
This is a non desirable situation, because an extension runs in the
same main loop than the whole desktop itself, which means that a
complex extension can need to do too much work inside the main loop,
and freeze the whole desktop for too much time. Also, it is important
to note that javascript doesn't have access to fork(), or threads,
which means that, at most, all the parallel computing that can do is
those available in the _async calls in GLib/GObject.
Also, having to create an extension for any priviledged graphical
element is an stopper for a lot of programmers who already know
GTK+ but doesn't know Clutter.
This patch wants to offer a solution to this problem, by offering a
new class that allows to launch a trusted child process from inside
mutter, and make it to use an specific UNIX socket to communicate
with the compositor. It also allows to check whether an specific
MetaWindow was created by one of this trusted child processes or not.
This allows to create extensions that launch a child process, and
when that process creates a window, the extension can confirm in a
secure way that the window really belongs to that process
launched by it, so it can give to that window "superpowers" like
being kept at the bottom of the desktop, not being listed in the
list of windows or shown in the Activities panel... Also, in future
versions, it could easily implement protocol extensions that only
could be used by these trusted child processes.
Several examples of the usefulness of this are that, with it, it
is possible to write programs that implements:
- desktop icons
- a dock
- a top or bottom bar
...
all in a secure manner, avoiding insecure programs to do the same.
In fact, even if the same code is launched manually, it won't have
those privileges, only the specific process launched from inside
mutter.
Since this is only needed under Wayland, it won't work under X11.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/741
Intended to be used to pass state from screen cast clients down the
line. The first use case will be a boolean whether a screen cast is a
plain recording or not, e.g. letting the Shell decide whether to use a
red dot as the icon, or the generic "sharing" symbol.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1377
GLib will now be linking against sysprof-capture-4.a. To support that,
sysprof had to remove the GLib dependency from sysprof-capture-4 which
had the side-effect of breaking ABi.
This bumps the dependency and includes a fallback to compile just the
libsysprof-capture-4.a using a subproject wrap.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1352
MetaBackgroundContent is a ClutterContent implementation
that can render a background to any attached actor. Right
now, it preserves all the properties and the rendering
model of MetaBackgroundActor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
Using XDG_CONFIG_HOME allows users to place their keyboard configuration into
their home directory and have them loaded automatically.
libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see
https://github.com/xkbcommon/libxkbcommon/pull/117
However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus
fails to load this for the mutter context which has cap_sys_nice.
We need to manually add that search path as lookup path.
As we can only append paths to libxkbcommon's context, we need to start with
an empty search path set, add our custom path, then append the default search
paths.
The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
