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>
Since we cache already all the KMS parameters we care about let's check at
each device update if anything has really changed and only in such case
emit a resources-changed signal.
In this way we can also filter out the DRM parameters that when changed
don't require a full monitors rebuild.
Examples are the gamma settings or the privacy screen parameters, that
emits an udev "hotplug" event when changed, but we want to register those
only when we handle the changed property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
It works correctly with scanouts, in contrast to
clutter_stage_capture_into. Inspired by
meta_screen_cast_area_stream_src_record_to_buffer.
maybe_paint_cursor_sprite is now unused and thus removed.
v2:
* clutter_stage_paint_to_buffer requires switching to recording from an
idle callback as well. (Jonas Ådahl)
v3:
* Set human readable name for idle source. (Ivan Molodetskikh)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1940
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1914>
In X11 when we switch to another tty all the the signals are blocked (as
the display fd is not replying back to polling, causing the main loop to
stop), and they are all handled once we switch back to the tty.
This is not a problem for most of external events, but in case of
accelerometer changes, once we reactivate a mutter session we'll get
them all together, causing lots of monitor reconfigurations leading to
black screen for some seconds and most of the times to a wrong
configuration being applied.
To avoid this, batch all these events using an idle to only apply the
last one we got in a loop.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1217
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
