This new manager object intends to take over management of the cursor
plane from the native cursor renderer. It's API is intended to be used
from the main thread, except for the _in_input() function, but mainly
operates in the KMS context, i.e. the KMS thread.
It makes use of an "update filter" that is called before each
MetaKmsUpdate is turned into a atomic KMS commit or a set of legacy
drmMode*() API calls. When the cursor position has been invalidated,
it'll assign the cursor plane in the filter callback, using an as up to
date as possible pointer position as the source for the cursor plane
position.
Cursor updates from the input thread schedules updates for the affected
CRTCs which will cause the filter to be run, potentially for cursor-only
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It currently does exactly what MetaKms and MetaKmsImpl did regarding the
context separation, which is to isolate what may eventually run on a KMS
thread into a separate unit. It works somewhat like a "user thread",
i.e. not a real thread, but will eventually learn how to spawn a
"kernel thread", but provide the same API from the outside.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This API aims to provide a way for users to capture input devices under
certain conditions, for example when a pointer crosses a specified
barrier.
So far only part of the API is implemented, specifially the session
management as well as zone advertisement, where a zone refers to a
region in the compositor which edges will eventually be made available
for barrier placement.
So far the remote access handle is created while the session is enable,
despite the input capturing isn't actually active yet. This will change
in the future once it can actually become active.
v2: Remove absolute/relative pointer, keep only pointer (ofourdan)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Hides libdisplay-info under a build time default-off flag,
provides provision to parse essential edid parameters with
APIs provided by libdisplay-info. This implementaion increases
readibility, avoids code duplication and decreases complexity
of edid parsing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2642>
Do the few remaining things that GDK is doing for us:
- Open and close the X11 Display
- Set up a GSource on the Display FD to handle events
- Allocate and free the content of XGenericEventCookie,
to "unroll" the few XInput2 events that Mutter still
does handle.
And remove the GdkDisplay we've so long relied on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
MetaRendererViewNative is a MetaRendererView which contains logic
specific to views of the native backend. It will be used by following
commits.
In the future, per-view logic from MetaRendererNative can be moved to
MetaRendererViewNative where it makes more sense to have it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
This class is intended to be used as a base class for D-bus interface
implementations that deal with "session" objects, i.e. a D-Bus object
representing a certain session of some kind, e.g. a screen cast session.
It handles things such as hooking up to the D-Bus client watcher,
generates IDs, handles shutdown procedures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This protocol is intended to let special clients create transient-for
relationships between X11 and Wayland windows. The client that needs
this is xdg-desktop-portal-gnome, which will create e.g. file chooser
Wayland dialogs that should be mapped on top of X11 windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The service channel D-Bus interface aims to be a "back door" for
services that needs special casing in Mutter, e.g. have custom private
protocols only meant to be used by that particular service.
There are currently no special casing implemented; only the basic
service channel infrastructure is added. There is a single method on the
interface, that is meant to eventually be used by
xdg-desktop-portal-gnome to open a Wayland connection with a private
protocol needed for the portal backend's rather special window
management needs.
The service channel Wayland client works by allowing one instance of
each "type", where each time needs to be defined to work in parallel. If
a new service client connects, the old one will be disconnected.
MetaWaylandClient's are used to manage the service clients, and are
assigned the service client type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
One can add a wl_global filter to a wl_display instance, which can be
used to decide what clients should see what globals. This has so far
been used to limit a Xwayland specific protocol extension to only
Xwayland. In order to expand the logic about what globals are filtered
to what clients, introduce a filter manager and port the Xwayland
specific protocol filter to this new manager.
Tests are added, using a new dummy protocol, to ensure that filtering is
working as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
This API creates a "client" then later sets up a wl_client and returns a
file descriptor some Wayland client can connect to. It's meant to be
used as a method other than WAYLAND_SOCKET and process launching, e.g.
passing a file descriptor via a D-Bus API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
This compositor-side object will single-handedly drive a window
drag operation. Currently, this largely copies meta_display_begin_grab_op
and meta_display_end_grab_op, except grabbing is done through a
ClutterGrab instead of direct meta_backend_grab_device() calls. This
also means that the switch from passive to active keyboard grabs is
handled differently.
Currently, this object is dormant. It requires moving more code from
other places to become a fully functional replacement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
When sysprof-4 and libsysprof-capture-4 are installed into different
prefixes, such as with Nix package manager, the D-Bus interfaces
are likely not discoverable from the latter package.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2572>
This replaces the v1 implementation, which is now renamed to
legacy-xdg-foreign. Both implementations use the same data structures
internally, so that protocol version mismatches between
the importer client and exporter client don't fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2770>
This small X11 client takes care of creating frames for client
windows, Mutter will use this client to delegate window frame
rendering and event handling.
The MetaWindowTracker object will keep track of windows created
from other clients, and will await for _MUTTER_NEEDS_FRAME property
updates on those (coming from Mutter), indicating the need for a
frame window.
This process is resilient to restarts of the frames client, existing
windows will be queried during start, and the existence of relevant
properties checked. Mutter will be able to just hide/show
SSD-decorated windows while the frames client restarts.
The frames are created through GTK4 widgets, the MetaWindowContent
widget acts as a replacement prop for the actual client window,
and the MetaFrameHeader wraps GtkHeaderBar so that windows can be
overshrunk, but otherwise a MetaFrame is a 100% true GTK4 GtkWindow.
After a frame window is created for a client window, the
_MUTTER_FRAME_FOR property will be set on the frame window,
indicating to mutter the correspondence between both Windows.
Additionally, the pixel sizes of the visible left/right/top/bottom
borders of the frame will be set through the _MUTTER_FRAME_EXTENTS
property, set on the frame window.
In order to make the frame window behave as the frame for the
client window, a number of properties will be tracked from the
client window to update the relevant frame behavior (window title,
resizability, availability of actions...), and also some forwarding
of events happening in the frame will be forwarded to the client
window (mainly, WM_DELETE_WINDOW when the close button is clicked).
Other than that, the frames are pretty much CSD GTK4 windows, so
window drags and resizes, and window context menus are forwarded for
the WM to handle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This helper struct takes care of the handling of requests and alarms
in order to satisfy NET_WM_SYNC_REQUEST. It will be necessary to
decouple rendering of windows and frames in future commits, so each
window may need its own synchronization and accounting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
v2:
* Use single hash table with struct which will contain all kinds of
state handled by a transaction.
v3:
* Add meta_wayland_transaction_destroy.
v4 (Georges Basile Stavracas Neto)
* Fix struct _MetaWaylandTransaction(Entry) formatting.
* Explicitly test against NULL.
* Use gpointer insteadof void * for
meta_wayland_transaction_entry_destroy.
v5: (Robert Mader)
* Use for loop in is_ancestor.
* Include meta-wayland-transaction.h first in
meta-wayland-transaction.c.
v6:
* Use g_autofree & g_clear_object.
v7: (Jonas Ådahl)
* Rename meta_wayland_transaction_entry_destroy to
meta_wayland_transaction_entry_free.
* Drop g_autofree use from meta_wayland_transaction_entry_free again.
* Make meta_wayland_transaction_entry_free take a
MetaWaylandTransactionEntry pointer.
* Rename meta_wayland_transaction_destroy to
meta_wayland_transaction_free.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
It's not really a backend thing, and we'll want to profile e.g. loading
the backend too, so create it very early and destroy it very late and
let MetaContextMain own it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2678>
Currently, the peripheral "output" setting will be unset if Mutter is
deciding automatically the mapped output of a tablet device. In that
case, gnome-control-center will have a hard time figuring out itself
the better output to show the tablet calibration UI, unless it's hand
held by Mutter.
Add this private D-Bus interface so that gnome-control-center can look
up the output as determined by Mutter to bring the missing harmony
between both. This interface consists of a simple method to get the
mapped output for a input device node.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2605>
Mutter can play sounds in some contexts and also provides an API
for libmutter users to do so using libcanberra internally.
In some specific use cases of Mutter, we would like to not depend
on libcanberra and not have any sound playing feature by default.
The changes keeps the sound player API but make it no-op if the
sound_player feature is disabled to not make it possible to break
a gnome-shell build.
See https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2270
for relevant discussion
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2375>
It uses the org.gnome.SettingsDaemon.Power.Screen D-Bus API. Currently
brightness set if the proxy is not ready are ignored; whether the
brightness value should be cached and set once it appears or whether
color profiles should be reapplied is yet to be decided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
Just as gsd-color does, generate color profiles. This can either be done
from EFI, if available and the color device is associated with a built
in panel, or from the EDID. If no source for a profile is found, none is
created.
The ICC profiles are also stored on disk so that they can be read by
e.g. colord. The on disk stored profiles will only be used for storing,
not reading the profiles, as the autogenerated ones will no matter what
always be loaded to verify the on disk profiles are up to date. If a on
disk profile is not, it will be replaced. This is so that fixes or
improvements to the profile generation will be made available despite
having run an older version earlier.
After generating, add some metadata about the generated file itself
needed by colord, i.e. file MD5 checksum and the file path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Previously, gsd-color handled adding color devices. It got information
about those via the GnomeRR API, which is part of libgnome-desktop.
libgnome-desktop itself got this information from the
org.gnome.Mutter.DisplayConfig.GetResources() D-Bus method, implemented
by mutter.
Now, mutter itself will add all the monitor color devices itself,
without having to go via gsd-color.
We sometimes need to delete colord devices synchronously, in certain
race conditions when we add and remove devices very quickly (e.g. in
tests). However, we cannot use libcolord's 'sync' API variants, as it
has a nested takes-all main loop as a way to invoke the sync call. This
effectively means we end up sometimes not return from this function in a
timely manner, causing wierd issues.
Instead, create our own sync helper, that uses a separate context that
we temporarly push as the thread-default one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Create a color manager type that eventually will be the high level
manager of color related behavior, such as ICC profiles and
color "temperature" a.k.a. night light.
For now, it's only an empty shell. It's also constructed by the actual
backend, as at a later point, the X11 and native color management
implementations will differ.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
The "single pixel buffer" Wayland protocol extension provides a way for
clients to create 1x1 buffers with a single color, specified by
providing the color channels (red, green and blue) as well as the
alpha channel as a 32 bit unsigned integer.
For now, this is turned into a 1x1 texture. Future potential
improvements is to hook things up to the scanout candidate logic and
turn it into a scanout capable DMA buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
This class is meant to hold logic specific to the native backend
in the context of a MetaCompositorView.
Its addition requires making MetaCompositorView inheritable, and an
addition of a virtual function which allows each compositor to create
its own MetaCompositorView instance.
In the case of the MetaCompositorNative, a MetaCompositorViewNative
is created. In all other cases, a MetaCompositorView is created.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
