All render devices that have a device file backing them might be able to
allocate dumb buffers, so add a helper for doing that. Will indirectly
result in an error up front on a surfaceless render device due to lack
of a device file.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It might not be needed by the user of the buffer, so don't always
require it up front. Instead make sure that any user that needs it first
calls "meta_drm_buffer_ensure_fb_id()" to create the ID.
Only the plain gbm implementation creates the ID lazilly, the other
still does it on construction due to the objects used to create them
only existing during construction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Mostly calls into gbm_bo_* API, or something somewhat similar when on
dumb buffers. Added API are:
* get offset for plane
* get bpp (bits per pixel)
* get modifier
This will allow users of MetaDrmBuffer to avoid having to "extract" the
gbm_bo to get these metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
The purpose of MetaRenderDevice is to contain the logics related to a
render device; i.e. e.g. a gbm_device, or an EGLDevice. It's meant to
help abstract away unrelated details from where it's eventually used,
which will be by MetaRendererNative and the MetaOnscreenNative
instances.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Meant for MetaRenderer and everything related that deals with turning
composited frames, or client buffers, into mode set updates. This is
slightly related to the debug topic 'kms' is meant for the KMS details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It was a feature relevant for when Clutter was an application toolkit
that wanted the application window to communicate a minimum size to the
windowing system.
Now, clutter is part of the windowing system component, so this feature
doesn't make any sense, so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This feature was configured depending on whether the Cogl backend
reported COGL_WINSYS_FEATURE_MULTIPLE_ONSCREEN or not. All cogl backends
do report this, so any code handled the 'static' case were never used.
While we only ever use one stage, it's arguable more correct to
consilidate on the single stage case, but multiple stages is something
that might be desirable for e.g. a remote lock screen, so lets keep this
logic intact.
This has the side effect of completely removing backend features, as
this was the only left-over feature detection that they handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This changes the setup phase of clutter to not be result of calling an
init function that sets up a few global singletons, via global singleton
setup vfuncs.
The way it worked was that mutter first did some initial setup
(connecting to the X11 server), then set a "custom backend" setup vfunc
global, before calling clutter_init().
During the clutter_init() call, the context and backend was setup by
calling the global singleton getters, which implicitly created the
backend and context on-demand.
This has now changed to mutter explicitly creating a `ClutterContext`
(which is actually a `ClutterMainContext`, but with the name shortened to
be consistent with `CoglContext` and `MetaContext`), calling it with a
backend constructor vfunc and user data pointer.
This function now explicitly creates the backend, without having to go
via the previously set global vfunc.
This changes the behavior of some "get_default()" like functions, which
will now fail if called after mutter has shut down, as when it does so,
it now destroys the backends and contexts, not only its own, but the
clutter ones too.
The "ownership" of the clutter backend is also moved to
`ClutterContext`, and MetaBackend is changed to fetch it via the clutter
context.
This also removed the unused option parsing that existed in clutter.
In some places, NULL checks for fetching the clutter context, or
backend, and fetching the cogl context from the clutter backend, had to
be added.
The reason for this is that some code that handles EGL contexts attempts
to restore the cogl EGL context tracking so that the right EGL context
is used by cogl the next time. This makes no sense to do before Cogl and
Clutter are even initialized, which was the case. It wasn't noticed
because the relevant singletons were initialized on demand via their
"getters".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
In various places we retrieved the default seat from the ClutterBackend.
All the clutter backends implement this by calling
meta_backend_get_default_seat() which will then return
MetaBackendPrivate::default_seat.
Lets avoid this by fetching the default seat directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
Rename all instances of `MetaClutterBackendX11` so they are called
`clutter_backend_x11`. This is because `MetaBackendX11` will start to be
used for some things, and having both be named `backend_x11` would be
confusing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This one is a trivial wrapper around clutter_actor_get_children(), so just
use that in the two places where clutter_container_get_children() is used,
and remove clutter_container_get_children().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2057>
Right now we damage the stage even if an actor is not mapped, for
example in the overview.
Stop doing so, reducing over-paint significantly in some situations.
Clones will still do stage damage on their own.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2035>
Quoting the spec for `wl_data_device::drop`:
> If the resulting action is "ask", the action will not be considered
> final. The drag-and-drop destination is expected to perform one last
> wl_data_offer.set_actions request, or wl_data_offer.destroy in order
> to cancel the operation.
We did not respect the action choosen by the drop destination when
it called `wl_data_offer::set_actions` after `wl_data_device::drop`
if a user override was still active. This eventually resulted in
a protocol error in `wl_data_offer::finish`, as the current action
could still be `ask`.
Fix this by only allowing a user override to `ask` before `drop` is
called, thus making sure the final `set_actions` preference is
honored.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1952
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2043>
Since the CI pipeline now runs `meson dist` which includes a test
for an up-to-date NEWS entry, post-branch/release version bumps
have become unwieldy.
It's still useful to increase the API version right after branching
though, so return to bumping it manually and do so now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2053>
With each wl_ouitput corresponding to a monitor, the logical monitor is
not part of the MetaWaylandOutput anymore.
Previously, send_xdg_output_events() would compare the old logical
monitor against the new one to determine whether the size and/or
position was changed and should be sent along with the xdg_output
events.
But that logic is now defeated as there is no old/new logical monitor
anymore, so the updated size or location would never be sent again.
Xwayland relies on this information to update its X11 clients and its
own internal root size, without this the X11 screen size and XRandR
information would never be updated.
To avoid that issue, always send the xdg_output size and location on
xdg_output events, Xwayland is smart enough to update its X11 clients
with XRandR only when the layout actually change.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1964
Fixes: bf7c3450 - Make each wl_output correspond to one monitor
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2050>
ClutterText implements its own get_paint_volume() with its own cache,
but was not invalidating the actor paint volume when when it has
changed. This sometimes could result in labels, especially quickly
changing ones, using the old paint volume which either would cut off the
label or leave parts of the old label on screen.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1943
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2006>
Easily seeing the buildtype and debug status can be quite useful.
Gnome-Shell already has it.
And while on it, add a 'Directories' section for already existing
entries.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2044>
meta_keymap_x11_replace_keycode currently reports to the X server
that the key types data is changed when adding a key to the keymap.
It's not changed. The number of key types is the same, and none of
them are modified.
This has two bad side effects:
1) It sends all of the key types data into the request
2) It hits a bug in the X server leading to the request getting
rejected entirely. See:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/761
Furthmore, the changed structure used to report to the X server
that the key types data is changed doesn't actually need to modified
at all in the function. It's already prepped by libX11 with the
correct state for the changes mutter is doing when
XkbChangeTypesOfKey is called.
This commit addresses the above two problems by just removing the
lines causing the issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2039>
Keys in the reserved keycode list are always added for the first group.
Before the previous commit such keycodes were not found unless that was
the current group. But now that we can also find matching keycodes that
are not directly in the current group, this is not necessary anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
Some keys, such as enter or backspace are only bound to a single group,
even if multiple groups are configured. Because the code was previously
only looking for keysyms in the same group as the current one, no
matching keycodes for these would be found if the current group is not
the first group. This was causing those keys to not work on the X11 OSK.
To fix this use the correct action to convert an out of range group for
that key according to its group_info field.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
This effectively changes meta_keymap_x11_get_entries_for_keyval() to
meta_keymap_x11_get_entry_for_keyval() and moves the check if the
keycode maps to the keyval in the current group there. This simplifies
the code a bit and will allow a followup fix.
As a side effect this now also causes the reserved kecodes to be
searched, if no keycodes were found, rather than just when only ones
matching the wrong groups.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
