When we use gbm together with the NVIDIA driver, we want the EGL/Vulkan
clients to do the same, instead of using the EGLStream paths. To achieve
that, make sure to only initialize the EGLStream controller when we
didn't end up using gbm as the renderer backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2052>
This switches the order of what renderer mode is tried first, so that
the gbm renderer mode is preferred on an NVIDIA driver where it is
supported.
We fall back to still try the EGLDevice renderer mode if the created gbm
renderer is not hardware accelerated.
The last fallback is still to use the gbm renderer, even if it is not
hardware accelerated, as this is needed when hardware acceleration isn't
available at all. The original reason for the old order was due to the
fact that a gbm renderer without hardware acceleration would succeed
even on NVIDIA driver that didn't support gbm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2051>
This replaces functionality that MetaRenderDevice and friends has
learned, e.g. buffer allocation, EGLDisplay creation, with the usage of
those helper objects. The main objective is to shrink
meta-renderer-native.c and by extension meta-onscreen-native.c, moving
its functionality into more isolated objects.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
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>
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 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>
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>
Avoid having laptops suspend or lock as soon as the power cable is
unplugged as the timeout for those actions when on battery are smaller
than the timeouts when on AC.
- laptop is plugged in, and hasn't been used for X minutes
- laptop is unplugged
- the gnome-settings-daemon power plugin sets up its timeouts for
inactivity for the "on battery" case
- those X minutes of inactivity are still counting, and are above
the level of one of the timeouts (say, suspend or lock screen),
mutter fires the timeouts
- gsd-power activates the action associated with the timeout
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1953
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2029>
When the native backend is paused we still process the udev events
even though this isn't needed and may just cause unneeded events to be
triggered afterwards.
Since we'll resume with full changes on such event, we can just block
the signal hander when paused and restore it afterwards.
As per this we can cleanup also a bit the device adding signal handling
given that now we don't have to disconnect/reconnect it again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Resume happens after we may have received various events that we've
ignored, so at this point we need to just emit an hotplug event like if
everything changed so that user settings may be re-applied.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may get informations about what CRTC or connector
changed a property (and the property itself), so in such case let's just
ignore the changes to the non-affected CRTCs/connectors, and let's read
only the affected one
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may receive a "CRTC" or "CONNECTOR" property that
indicates which crtc/connector property ID has changed.
In such case, instead of update data for all the devices, only update the
device containing the relative connector.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Hotplug events may contain CRTC or CONNECTOR ids to notify a property
change to just one owner, so we need to find its parent device.
Also we may want to update properties directly without having to go through
all the devices, so expose a simple way to find them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
In case we have no devices, after a KMS update (both because they've
all have been removed or because there were none), we may need to behave
differently compared to the case in which nothing changed, so add a more
specific KMS update change type
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
If only gamma changed on drm CRTC's we don't have to rebuild the whole
monitors, nor to inform the backed about, the only consumer could be the
DBus API, and so we still emit a signal, but nothing else is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
