This adds the 4 new connector types that mutter didn't know about from
drm_mode.h in the kernel.
Noticed because mutter kept crashing when plugging in a USB-C adapter to
use an external monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2577>
When we e.g. generate switch configs (i.e. the ones from pressing the
Super+P or the switch-config key on laptops), try a bit harder to find a
"good" monitor scale.
With "good", it means pick a scale that was used in a previous
configuration. In practice, this means that if you for example have
configured your external monitor to use a specific scale, then pressed
e.g. "built in only", and then switched back to e.g. "external only" or
"linear", the generated configuration will use the scale that was
previously configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
If two modes are roughly the same, they should probably use the same UI
scaling factor. I.e. for the same monitor, if a 4K mode was configured to
have a certain scaling factor, and we generate a new configuration with
a similar sized 4K mode, we should re-use the scale previously
configured; however if we e.g. go from a 4K mode to a FHD mode, we
shouldn't.
This allows implementing better hueristics when using the switch-config
feature, where we'd be less likely to loose the for a certain monitor
mode combination previously configured scaling factor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This will eventually help with better hueristics for finding a good
scale. It currently doesn't change much, but the helper will later gain
more functionality that will also help when coming up with mirroring
configs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
The resulting logical monitor was eventually marked as primary anyway,
but without the config being marked as such, various primary properties
was not set e.g. the one on the MetaOutput. Also, tests would fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This will allow tests to change monitor resolution. The first argument
is the monitor ID; there is always one monitor added by default, and it
has the id 0. It's currently not possible to add more monitors, so
passing '0' is the only valid way to resize monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This allows the GL fallback path to correctly paint the cursor
if clients pre-rotated the buffer using
`wl_surface::set_buffer_transform`, visually matching the
hardware cursor path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/344>
When taking the scanout path we still want to clear the
redraw-clip from the stage-view in order to ensure we skip
frames in `handle_frame_clock_frame()` if no new redraw-clip
was recorded.
This was not done previously as the accumulated redraw-clip was
needed for the next repaint, likely under the assumption that
scheduling a scanout repeatedly would be computationally cost-free.
This assumption does not hold in a VRR world.
In order to archive both, an accumulated redraw-clip for the next
paint and frame-skipping during scanout, introduce new API to defer
and accumulate redraw-clips until the next repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2480>
We disable modifiers for two reasons: an udev rule saying so, or the
lack of a working drmModeAddFB2(). However, to the users, this is not
granular enough. While the current user, whether to enable modifiers in
MetaRendererNative, doesn't need more granularity, we want to send
modifiers to Wayland clients even if the onscreen framebuffers should
still be allocated without modifiers.
Prepare for differentiating between how Wayland DMA buffers work and how
onscreen buffer allocation work by separating the relevant device flags.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2546>
This one does proper error reporting. Via Javascript, barriers are
constructed directly via GObject construction, which currently can't
handle error reporting, but when calling from C we can. However, if we
initialize using GInitable, and use that in our constructor method, once
gjs gains support for construction using GInitable, including the error
reporting, we'll automatically get proper error reporting to Javascript.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
Prior to this commit, barriers were created with a MetaDisplay pointer,
despite being entities related and owned by the backend. In the X11
case, it was also not hooked up to the backend X11 connection, but the
clutter one, meaning for example that the logic was active (but dormant)
also for the Xwayland connection.
Fix this by moving X11 barrier management and event processing fully to
the backend. Also replace passing a display pointer with passing a
backend pointer. Keep the display pointer around for a release, but mark
it as deprecated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
It papered over wrong `meta_rectangle_transform()` behaviour for
non-flipped output transforms. Also there is no obvious reason
why we would need inverted values here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
- Drop bogus `meta_monitor_transform_invert()`. It papered over
wrong `meta_rectangle_transform()` behaviour for non-flipped
output transforms.
- Update `scale_and_transform_cursor_sprite_cpu` to match the GL
pipeline matrix in `MetaShapedTexture`, fixing several of the
flipped cases. Note: the rotation applied is the one a client would
need to apply to the buffer for a given monitor transform.
- While on it, drop a redundant `return`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
The following implicit definition for `transform()` did not
correctly apply:
```
a * b = c
c * invert(b) = a
```
Crucially the following did not apply for `FLIPPED-90`
and `FLIPPED-270`:
```
a * invert(a) = identity
```
Fix this by applying the operations, first the flip, then the
rotation, in this order and add tests to ensure correct results
for the requirement above.
Also drop `relative_transform()` as it only had a single user and
can be replaced by `transform()`:
```
invert(a) * b = c
a * c = b
```
As this is not very intuitive, ensure in tests as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
Checking for both bits at once means only one matching bit is
sufficient - very likely in case of `rotate-0'.
This fixes crashes on hardware that does not support 'reflect-'
bits when setting a flipped output transform.
While on it, also update the check for `reflect-y` instead of
`reflect-x` + `rotate-180`. They are logically equivalent,
however some hardware may support `reflect-y` but not both
other bits.
Fixes commit 4e3f3842a1
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
We started to report resource changes using prediction when an update
had been successfully committed. While at it, gamma changes were
reported too, but this was problematic, as gsd-color will listen for the
MonitorsChanged D-Bus signal and naively set the gamma again, even if it
didn't change. There aren't currently any actual use cases for being
told when gamma changes from a prediction, so just ignore it and just
report privacy screen changes.
This avoids a feedback loop between mutter and gsd-color.
Fixes: 81b28a1d97
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2531>
When we change the privacy screen, we added a result listener to the KMS
update object to notify the upper layer about the privacy screen state
change. This was slightly awkward as one might have changed the state
multiple times for a single update, thus it was necessary to remove any
old result listeners to an update before adding a new one.
Doing this will not be possible when updates are fully async and managed
by the KMS impl device.
To handle this, instead make the post-commit prediction notify about
changes that happens in response to a successfully committed update. We
already predicted the new privacy screen state, so the necessary change
was to plumb the actual change into a callback which emits the signal if
there actually was a privacy screen change.
This will then be communicated via the same signal listener that already
listens to the 'resources-changed' signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2340>
The name had a bit conceptual conflicts with MetaKmsUpdate, as it shared
its namespace but had no relation to it. Fix this by renaming it
MetaKmsResourceChanges (and the corresponding META_KMS_UPDATE_CHANGE_*
to META_KMS_RESOURCE_CHANGE_*). The term "resource" is used since that's
already used in the signal, and the fact that the changes partly comes
from changes in the DRM resource as retrieved by drmModeGetResources.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2340>
With this header we can set a flag to signal that the whole buffer is
corrupt and should be ignored. With this we can cater to all cases:
* Window buffer fine, but cursor broken:
Use the spa_meta_cursor properties like id or offset accordingly
* Window buffer broken, but cursor fine:
Use the chunk flags
* Both are broken / the dequeued buffer is not usable
Use the spa_meta_header flag
Additionally clients can now check if a buffer contains spa_meta_header
data and can thus only check for the new or the old behaviour.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2516>
Since the commit below, meta_crtc_kms_get_cursor_renderer_private has
returned a CrtcCursorData pointer, but this code was still treating it
as a MetaDrmBuffer pointer.
Fixes: fea8ebcca9 ("cursor-renderer/native: Store struct in CRTC private")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2524>
PipeWire supports flags to signal a corrupted buffer. We should use the
flag SPA_CHUNK_FLAG_CORRUPTED for `chunk->flags` instead of setting
`chunk->size = 0` since the size isn't well defined for arbitrary dmabufs
and should be set to 0.
Sadly clients like obs are using a chunk size of 0 to decide if a buffer
should be imported. Thus we should offer both until clients are using
the flag.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2323>
Change meta_seat_impl_notify_discrete_scroll_in_impl to receive 120
based values and report high-resolution scroll values as smooth scroll.
Notify discrete scroll only when the accumulated value reach 120.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
In order to get the delta X/Y value of the
LIBINPUT_EVENT_POINTER_SCROLL_FINGER
or LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS events the new function
libinput_event_pointer_get_scroll_value should be used instead of
libinput_event_pointer_get_axis_value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
Ignore deprecated LIBINPUT_EVENT_POINTER_AXIS events and handle
LIBINPUT_EVENT_POINTER_SCROLL_WHEEL,
LIBINPUT_EVENT_POINTER_SCROLL_FINGER and
LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS instead.
The scroll source is now encoded in the event type making
libinput_event_pointer_get_axis_source and translate_scroll_source
redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
This adds support for E-EDID extensions. Tags are allocated by VESA and
the CTA has such an extension defined in CTA-861.
The switch in `decode_ext_cta` is empty in this commit because we don't
parse any CTA-861 data blocks, yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2351>
The EDID code is copy from elsewhere, without adapting to conventions
regarding e.g. API and types. Clean this up a bit, as EDID information
will be kept around longer when possible, to be used e.g. by color
management.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2351>
The pixel clock determines how fast pixels can be processed. When adding
non-native common modes, avoid adding modes that exceed the max pixel
clock frequency of the native modes. Avoiding these avoids potential
mode setting failures where the GPU can't handle the modeline since the
configured pixel clock is too fast. This replaces the "bandwidth" check
which used the number of pixels and refresh rate, which wasn't enough to
avoid incompatible modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2492>
'screen-cast/monitor-src: Use clutter_stage_paint_to_buffer'
(6c818cd8d5) made the non-dma-buf path use
clutter_stage_paint_to_buffer() to avoid running into direct scanout
issues. At a glance, the dma-buf paths didn't have the same issue since
it explicitly handled dma-bufs by blitting them.
What it also did was move the recording to an idle callback, to avoid
paint reentry issues. A side effect of this, however, is that it also
broke the dma-buf paths, as they rely on the back buffer existing, and
the stage view direct scanout already being setup, which it isn't in an
idle callback.
Fix this by using the dma-buf variant of
clutter_stage_paint_to_buffer(): clutter_stage_paint_to_framebuffer().
This has some negative performance impact, but we can't use
cogl_blit_framebuffer() when using an idle callback for recording.
Potential performance improvements to make things work more as they did
before is to enhance 'cogl_blit_framebuffer()' a bit, making it a vfunc
that could be implemented by MetaOnscreenNative. A flag to say whether
to look at the back or front buffer would let MetaOnscreenNative know
whether to use the already committed-to-KMS buffer, or the current back
buffer.
Fixes: 6c818cd8d5
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2282
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2462>
The MetaKeyboardA11yFlags are used by gnome-shell to show a dialog
whenever a keyboard accessibility feature is switched using the
keyboard.
Unfortunately, commit c3acaeb25 renamed the Clutter flag to Meta and
moved them to a private header. As a result, gnome-shell do not show any
dialog anymore when a keyboard accessibility feature is activated.
Move the MetaKeyboardA11yFlags definition to a public header so that
gnome-shell can use it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2306
Fixes: c3acaeb25 - backends: Move keyboard a11y into backends
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2463>
The min distance to the right/bottom edge depends on Wayland concepts
(wl_fixed_t) and eventually geometry scale. Move the logic the Wayland
side of the pointer constraints machinery to avoid the backend trying to
figure this out without the proper data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
There were some coordinate nudging to avoid running into Clutter
floating point math issues related to coordinate transformations. Over
the years these things have improved, especially with the move to
graphene, so remove the old work around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
The ImplDeviceAtomic converts the MetaKmsPlaneRotation back to the
concrete KMS value. The MetaMonitorTransform is always directly
converted to a MetaKmsPlaneRotation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
Updating the PropTable has the side effect that the parse callback now
also gets called on hotplug but it is used to initialize data. The parse
callbacks are moved to the read_state functions which are aware if this
is an initializing call or just an update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
We don't make use of the refresh rate in any useful way in the X11, and
in this case we just ended up with warnings since the refresh rate was
NaN. Fix this by making it 0.0 to mean "no refresh rate". This also is
what 'xrandr' itself reports.
Fixes warnings when launching 'mutter --x11' in Xvfb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
This adds a minimalistic fullscreen direct scanout test case, that runs
on vkms. It doesn't use EGL, and it uses uninitialized memory, thus it
lacks any kind of implicit synchronization, but it does test that the
scanout selection paths are working.
What is tested is:
* DMA buffer allocated using gbm on top of VKMS
* Buffer passes a mode setting TEST_ONLY check
* Paint is omitted
* Correct buffer active in KMS after presentation
What isn't yet tested:
* Implicit synchronization related behavior
* Presented pixel content
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2417>
The property doesn't necessarily exist when using drivers that doesn't
support atomic mode setting, and the way it worked will break night
light and other gamma related features. This makes things use the gamma
length; if it is higher than 0, it definitely supports it one way or the
other, i.e. GAMMA_LUT with the atomic backend, and drmModeCrtcSetGamma()
with the legacy/simple backend.
Fixes: 364572b95c
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2287
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
It doesn't depend on whether the CRTC is active or not, so always read
it. This is also useful to know whether a CRTC supports gamma, before it
is being turned on, without relying on the existance of properties.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
Mutter makes use of a gsettings scheme that comes from
gnome-settings-daemon to check for the screen orientation.
In use cases where gnome-settings-daemon is not available,
this would lead to a crash as the key doesn't exists
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2398>
The monitors settings such as the privacy screen property is propagated
to the monitors via kms updates, however during initialization and
on monitors changes, we end up clearing the pending KMS updates because
such settings are added to the queue before the backend has fully
initialized the monitors, and this may lead to discarding all the
pending updates, including the one we've just planned.
To avoid this, move settings applications after we've both initialized
the backend and notified it about changes.
Also avoid to try set the settings during actual initialization, but
delay that after post-init.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2372>
'kms/impl-device/simple: Get the buffer handle from MetaDrmBuffer'
changed how fb ids are generated, but it only made it fully work with
atomic mode setting. For legacy/simple mode setting, it only handled the
primary plane buffer, not the hardware cursor.
Fix this by making sure the fb id is generated also in the legacy mode
setting case.
Fixes: ea39142da2
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2250
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2397>
With the unthrottled input emission, we ended up often getting the
cursor updates long before any damage had been posted, meaning that if
you moved around the mouse pointer where the mouse had a high enough
refresh rate, we'd effectively stall the screen cast stream by only
sending cursor updates and nothing else.
Fix this by scheduling an update when we get a cursor update, then
sending a cursor-only frame after any damage and relayout has been
processed, but only if there is no queued damage that will cause an
actual repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
This handle is used by the legacy KMS API; lets avoid having to have GBM
specific code where this is done by letting the MetaDrmBuffer API, that
already has this information, expose it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
DMA buffers might be allocatable, but it doesn't mean the driver doesn't
fail when we try to allocate a buffer with an implicit modifier. Using
the proprietary NVIDIA driver for example, it will fail. Lets catch this
up front and avoid advertising DMA buffer support when we know it won't
work.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2383>
MetaCursorRendererNative only updates the cursor state when the
underlying texture changes. The cursor scale and transform do not
trigger updates. This results in wrong cursor orientations on rotated
displays. Use both texture changes and scale and transformation changes
to figure out when to update the cursor state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2363>
We rather confusingly still call a secondary display card that is
GPU-less (DisplayLink or other basic KMS device) a "secondary GPU",
so just because secondary_gpu_state is non-NULL doesn't mean we
can use it for rendering. The clearest indication of this is when
there is no EGL surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2341>
Since devices may be multiple things now, check all capabilities in order
to ensure all aspects of the device are correctly configured.
This change does the following observations:
- Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad'
settings path. The regular pointer settings path is left for all
non-touchpads.
- Devices that are both a tablet and a touchscreen prefer the tablet
relocatable schema. This works for both aspects as the touchscreen
schema is a subset of the tablet one.
Other than that it's a rather boring, even if verbose search and replace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
We do not need to open code the ClutterInputDeviceType fetching from a
libinput_device, since we already created a native ClutterInputDevice that
has the right type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
If the remote desktop service emits absolute input events (e.g. absolute
pointer events) before the stream has started streaming, we don't have a
virtual monitor, as the size has not been negotiated yet. When this
happens, just drop the event. Remote desktop services should probably
make sure not to send events before the streaming has started, but them
doing so anyway shouldn't trigger a crash, which would be the case
otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
Keep the virtual monitor around if it's being resized. This reduces the
number of unnecessary object rebuilding that happen during monitor
rebuilding.
This changes finalize() vfunc into a dispose() vfunc in the abstract
stream source object implementation, as it needs the abstract stream
source object to close the stream early, so that various signal
listeners get disconnected early.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1904
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
We'll change mode's on-demand so using IDs identical to the virtual
monitor ID would mean IDs didn't change when changing mode, and that is
rather unintuitive. IDs don't mean much anyhow, just make them grow
within the realm of a 63 bit unsigned integer, as the 64th bit means its
a virtual mode ID. Making sure the ID is in the virtual mode namespace
is handled by meta_crtc_mode_virtual_new().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
This implements the new 'bounds' event that is part of the xdg_toplevel
interface in the xdg-shell protocol. It aims to let clients create
"good" default window sizes that depends on e.g. the resolution of the
monitor the window will be mapped on, whether there are panels taking up
space, and things like that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
gnome-desktop is used to retrieve the monitor vendor name which in some
use cases is not needed as it brings a bunch of gnome-desktop unwanted
dependencies.
The change makes mutter fallback to an "Undefined" vendor name if it is
built without gnome-desktop
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2317>
Return in meta_egl_choose_all_configs() the actual number of
configurations returned by eglChooseConfig(), which are not
necessarily the same number as those from eglGetConfigs().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2303>
Since the introduction of ClutterGrabs, MetaDnd now no longer gets
notified about input events on the stage during grabs (for example while
the alt-tab popup is shown) and thus can't move the grab feedback actor
anymore.
To fix this, forward events to MetaDnD directly from
meta_display_handle_event() when a ClutterGrab is in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
It passes a MetaLogicalMonitor, which isn't introspected right now, so
skip it completely. The entry point to the UI is handled via
MetaDisplay, so it isn't needed.
This fixes the following warning:
<unknown>:: Warning: Meta: (Signal)monitor-privacy-screen-changed: argument object: Unresolved type: 'MetaLogicalMonitor'
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2287>
We update some details like the last used device and pointer visibility
from events, but this is done inconsistently on X11 since the
ClutterEvents are created and pushed from an additional place.
Make these updates happen on a private call, that will be called from
these places in X11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
Even though it's great that XI2 has an event to notify about device
changes, this is something we can let the MetaBackend code handle
consistently for all backends, since looking for the source device
works everywhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
Instead of relying in the device being updated from different parts of our
machinery for different backends, hook this up to our own event dispatching.
This will allow dropping all other places where this is done.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
We create a cursor renderer per device for those at
meta_seat_native_handle_event_post() with PROXIMITY_IN events, but
the MetaWaylandTabletTool handles the event before that, and goes
with a NULL cursor renderer.
Make MetaBackend::get_cursor_renderer() on the native backend create
those cursor renderers on demand, and only handle PROXIMITY_OUT in
handle_event_post() to dispose those. This makes MetaWaylandTabletTool
happily get a cursor renderer again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
We now only enable DMA buffer based PipeWire screen casting if a
format/modifier has been negotiated. This practically means a consumer
is aware about what is needed, and we should not try to predict that it
uses the DMA buffer the right way (i.e. not mmap:ing directly).
However, in case we're not hardware accelerated, we never want to
attempt to use DMA buffer screen sharing, as we want to avoid
compositing into a DMA buffer on such hardware as doing so can be very
slow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2086>
When handling lid state, we used to update the idle time right after
opening the lid. This behavior changed in commit 14b6c8780d due
to a typo/thinko, "if (lid_is_closed)" used to be an early return
condition before updating idle time, now it only updates in that
case.
Restore the original behavior, since this idle time update is key
in having gsd-power light up the display again, this presumably
fixes situations that required extra "light up" hints after suspend.
What it does surely fix is "ninja test" in g-s-d against recent
mutter, since the behavioral change induced a test timeout there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2272>
Add some debug logging that allows checking whether we're using DMA
buffers for screencasting or system memory buffers. This can be useful
for debugging screencasting performance and CPU usage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2256>
With the ability to query the renderer for DMA-BUF support we can
announce support for implicit modifiers. This allows PipeWire to check
for matching modifiers while negotiation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
Returns TRUE if the active renderer backend can allocate DMA buffers.
This is the case hardware accelerated GBM backends, but FALSE for
surfaceless (i.e. no render node) and EGLDevice (legacy NVIDIA paths).
While software based gbm devices can allocate DMA buffers, we don't want
to allocate them for offscreen rendering, as we really only use these
for inter process transfers, and as buffers allocated for scanout
doesn't use the relevant API, making it return FALSE for these solves
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
Because both code paths require the existence of `GL_TIMESTAMP[_EXT]`
which is only guaranteed if `ARB_timer_query` (included in GL core 3.3)
is implemented.
We know when that is true because `context->glGenQueries` and
`context->glQueryCounter` are non-NULL. So that is the minimum
requirement for any use of `GL_TIMESTAMP`, even when it is used in
`glGetInteger64v`.
Until now, Raspberry Pi (OpenGL 2.1) would find a working implementation
of `glGetInteger64v` but failed to check whether the driver understands
`GL_TIMESTAMP` (it doesn't).
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2107
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2253>
Adding a <dbus/> element containing a boolean (yes/no) determines
whether org.gnome.Mutter.DisplayConfig ApplyMonitorsConfig will be
callable. The state is also introspectable via the
ApplyMonitorsConfigAllowed property on the same interface.
For example
<monitors version="2">
<policy>
<dbus>no</dbus>
</policy>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
This adds a way to define a way, at the system level, to define a policy
of how monitor configuration files are loaded.
The intended use case is to e.g. either prefer system level monitor
configurations before user levels, or only allow system level
configurations.
Examples:
Prefer system over user level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
<store>user</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Only allow system level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
strncmp() always return 0 if the passed length is 0. What this means is
that whatever the first string check happens to be, if the parsed XML
cdata was empty (e.g. if we got <element></element>), the first
condition would evaluate to true, which is rather unexpected.
Fix this by making sure the string length is correct first. Also move it
into a helper so we don't need to repeat the same strlen() check every
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The way device backends implement power saving differ, and power saving
needs to contain nothing incompatible in the same update. Make it
impossible to e.g. mode set, page flip, etc while entering power save by
not using MetaKmsUpdate's at all for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
When we're predicting state, i.e. when having posted an update while
avoiding reading KMS state, copy the predicted state, update the actual
state, and check that the predicted state matches the newly updated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
