And stop passing in the color states from the RendererNative. We also
keep the color states updated by listening for changes in the color
device.
The RendererX11Cm has a single view and no mapping to a specific color
device, so we handle the absense of a color device as well and rely on
ClutterStageView to have the default color states.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3930>
This allows us to destroy and create a new offscreen dynamically, when
the rotation or color state changes.
An idle gsource with priority higher than CLUTTER_PRIORITY_REDRAW is
used to ensure the an offscreen exists when required without having to
allocate in the redraw process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3930>
by executing `global.context.get_debug_control().exported = true`.
This makes it possible to get access to the debug service without having
to start with `--enable-debug`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3902>
Allow compositing in a linear color space and do so either when forcing
it via the debug controls D-Bus API, or when the experimental HDR mode
is enabled.
This relies on paint nodes etc to actually transform everything into the
linear target color space, which isn't done yet, so enabling it right
now will cause a broken result. Yet, introduce this now, so that
painting can be fixed piece by piece.
Linear blending is automatically enabled on monitors where HDR is
enabled, as this makes it possible to use an linear color space when
blending content from different color spaces with different transfer
functions.
Linear blending requires extra precision, i.e. 16 bit per channel
in the intermediate buffer due how the values are distributed,
so only enable the experimental HDR mode if the Cogl context supports
half float formats.
By default, no intermadiate linear offscreen framebuffer is used.
To test, do e.g.
./tools/debug-control.py --toggle ForceLinearBlending
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
It's constructed as a native backend headless backend, but uses a custom
monitor manager (based on MetaMonitorManagerNative) that creates a fake
monitor. Rendering is unconditionally done with the surfaceless
renderer.
The test devices used now use virtual devices, meaning some changes to
the tests to e.g. not set names, and not dealing with input devices
directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
If view initialization fails then don't add the view, rather than
adding a dummy offscreen view. This avoids flooding the log with
offscreen frame clock confusion:
Before:
```
libmutter-WARNING **: 15:47:27.763: Failed to allocate onscreen framebuffer for /dev/dri/card0: Failed to allocate surface: Function not implemented
Clutter-WARNING **: 15:47:28.557: (../clutter/clutter/clutter-frame-clock.c:419):clutter_frame_clock_notify_presented: code should not be reached
Clutter-WARNING **: 15:47:28.563: (../clutter/clutter/clutter-frame-clock.c:419):clutter_frame_clock_notify_presented: code should not be reached
Clutter-WARNING **: 15:47:28.567: (../clutter/clutter/clutter-frame-clock.c:419):clutter_frame_clock_notify_presented: code should not be reached
(repeats forever)
```
After:
```
libmutter-WARNING **: 16:09:04.945: Failed to create view for Unknown 46" on None-1: Failed to allocate onscreen framebuffer for /dev/dri/card0: Failed to allocate surface: Function not implemented
```
Relates to:
https://launchpad.net/bugs/1967707https://gitlab.gnome.org/GNOME/mutter/-/issues/2489https://gitlab.gnome.org/GNOME/mutter/-/issues/2295
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3115>
In the rare event that hotplugs destroy and then create a new EGLContext
with the exactly the same ID, this ensures we will forget the old program
which presumably wouldn't work in the new context. It will be recreated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
meta_render_device_gbm_allocate_dma_buf() function is updated to take a
list of modifiers. If no modifiers are specified, the modifier is
selected by the allocator, and implicit modifiers are used to import the
created DMA-BUF.
Co-authored-by: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3537>
For secondary GPU rendering contexts we currently might choose an EGL
config with a format which is not supported on all primary planes. The
renderer is created when a GPU is detected and lighting up outputs and
thus assigning CRTC and primary planes can happen at any point after
that. This means we have to make sure that all possible plane
assignments will work with the rendering context when we create it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3235
Fixes: cc7bca073 ("crtc/kms: Dynamically assign primary and cursor planes")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3512>
When there are a set of primary planes, and a set of CRTCs, where each
plane can be used on multiple CRTCs, we need to make sure that when we
mode set and page flip, each CRTC gets assigned an individual plane that
isn't used with any other CRTC.
Do this during the monitor resource assignments that sets up later to be
applied configurations of the mode setting objects, but with the new
hooks into the backend, so that we don't need to teach the monitor
config manager about planes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2398
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
For scanout on a secondary GPU, for the time being try only formats
which are guaranteed to be renderable with GLES3, which notably excludes
10 bpc formats without alpha channel.
v2:
* Use separate format array for 10 bpc formats without alpha.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
If the EGL_KHR_no_config_context extension is supported, use it to
choose a format per onscreen which is compatible with the scanout CRTC
and the GL rendering API used.
Suggested by Jonas Ådahl.
v2:
* Drop code which checked for GLES3 renderability. Makes no sense for
various reasons, in particular that EGLconfigs are about EGLSurfaces,
whereas secondary GPU contexts use an FBO for blitting.
* Use error parameter directly for meta_renderer_native_choose_gbm_format
call (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
Preparation for the following commits, no functional change intended.
v2:
* Pass through MetaEgl pointer
v3:
* Make it return gboolean (Robert Mader)
v4:
* Add debug logging and corresponding purpose parameter
v5:
* Fix excessive function parameter indentation (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
When running headless, only the invalid modifiers are advertised.
That breaks with the NVIDIA proprietary driver which then rejects the
buffers created with the invalid modifier, and that kills Xwayland,
meaning that running Xwayland on top of a mutter based compositor
headless is not possible.
The reason the modifiers are not sent is because AddFb2 is not supported
when running headless.
Other compositors (weston, wlroots) would still send the modifiers even
without AddFb2, and Xwayland works fine on those compositors when
running headless.
Remove the requirement for AddFb2 to send the modifiers, so that
Xwayland can work fine on top of mutter headless with the NVIDIA
proprietary driver.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3060
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3320>
If we queued a mode set, but didn't end up compositing all frames, we'll
have pending mode sets in a hash table waiting to be applied. If we
before all monitors again try to reconfigure things we should drop the
old pending mode sets and start fresh.
We already do this when we're doing so when generating views, but when
just unsetting modes, we didn't, so fix that.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2242612
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3318>
We had a function called "reset_modes()" on MetaRendererNative, but what
it expected to do was to unset all modes on all CRTCs. Despite this, it
had code to unset modes on unconfigured CRTCs, probably because it was
used for multiple things in the past.
Make this a bit easier to follow by renaming the function
"unset_modes()" and fold the function doing the unsetting into the
function itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3318>
If we are making an update that only disables CRTCs, we would not
actually post it, but just drop it then post nothing, as it wasn't ever
added to the mode set update hash table. This resulted in hotplugs where
we loose the all the connectors we had, where we want to disable all
CRTCs and enable nothing, to fail to disable said CRTCs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3073>
We need to trigger a mode set when power-save changes to 'on' if it's
purely about power saving, but when they arrive as part of a hotplug
event, we'll handle all that later, in the monitors-changed handling,
that contains the new configuration.
This avoids a crash that happens due to the mode set being queued on now
disabled connectors.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2985
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3233>
We can change power save mode for two reasons: gsd-power told us to, or
we saw a hotplug event. Sometimes it's useful to be able to make the
distinction to why a power save mode changed, so add a reason to the
signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3233>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
So they can be derived from the DRM format as well.
While updating the users, ensure we don't announce support for
DRM formats in zwp_linux_dmabuf_v1 if the MetaMultiTextureFormat is
INVALID. This will be used for YUV subformats in following commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
1. Move into the new 'common' folder and build for Wayland as well
so we will be able to share the code in follow-up commits.
2. Rename to cogl-drm-formats to make it more obvious that the format
map is more than an utility these days.
3. Drop the unused CoglTextureComponents part (see also previous
commit).
4. Move the map to the header, simplifying some future use-cases.
5. Sync formats with MetaWaylandBuffer and MetaWaylandDmaBufBuffer and
also use newly introduced opaque formats where appropriate.
This avoids duplicated code, ensures that new drm-formats added to
the dmabuf protocol have an adequate representation in Cogl from which
information like alpha support can be easily derived and finally
ensures we don't crash if the mappings got out of sync.
6. Remove some likely untested formats. In case some of these are
actually needed on certain hardware, we can test whether we got
the correct mapping by also adding support for the corresponding
wl_shm_format in MetaWaylandBuffer by extending the gradient test in
https://gitlab.freedesktop.org/jadahl/wayland-test-clients
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
