The connector state wasn't properly predicted, as it earlied out if
the connector wasn't part of a mode set connector list.
Instead use the old CRTC to check whether it was used in any mode set,
and whether the connector was part of any new mode set, to predict
whether the connector is inactive or active.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
When a device only had mode sets which turned off monitors, not enabling
anything, there would be no KMS update created and posted, and the
active monitors would remain on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
On hybrid graphics system, the primary path used to transfer the stage
framebuffer onto the dedicated GPU's video memory preparing for scanout,
is using the dedicated GPU to glBlitFramebuffer() the content from the
iGPU texture onto the scanout buffer.
After we have done this, we reset the current EGL context back to the
one managed by cogl. What we failed to do, however, was to reset the
current EGL context when we inhibited the actual page flip due to having
entered power save mode.
When we later started to paint again, Cogl thought the current EGL
context was still the correct one, but in fact it was the one used for
the iGPU -> dGPU blit, causing various EGL surface errors, and as a side
effect, eventually hitting an assert.
Fix this by making sure we reset to the Cogl managed EGL context also
for this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
Destroying the EGLSurface frees the underlying container structs. When
we call gbm_surface_release_buffer() with a gbm_surface the EGLSurface
was created from, doing that after the EGLSurface was destroyed results
in attempts to access freed memory. Fix this by releasing any buffer
first, followed by destroying the EGLSurface, and lastly, the
gbm_surface.
This was not a problem prior to CoglOnscreen turning into a GObject, as
in that case, the dispose-chain was not setup correctly, and the
EGLSurface destruction was done in the native backend implementation.
This also changes a g_return_if_fail() to a g_warn_if_fail(), as if we
hit the unexpected case, we still need to call up to the parent dispose
vfunc to not cause critical issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
It's handled by CoglOnscreenEgl's dispose() implementation. It was
failed to be invoked in the past because the old non-GObject web of
vtables were not setup correctly, meaning the old generic EGL layer of
the CoglOnscreen de-init was never invoked.
When the type inheritence was cleaned up, this mistake was not cleaned
up, so do that now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
Meson doesn't seem to handle depending on generated headers, at least
when those headers are pulled in indirectly via another header file.
Luckily, we don't actually need to include the generated D-Bus boiler
plate in meta-monitor-manager-private.h, since the MetaMonitorManager
type no longer is based on the D-Bus service skeleton.
So, by moving the inclusion of the generated D-Bus header file into
meta-monitor-manager.c, we should hopefully get rid of the sporadic
build issues.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1819>
If there was only a single mode, add the common modes to provide options
to select other resolutions than the built in default. This avoids
issues where the connector listed multiple supported modes, but where
the common modes added would exceed the possible bandwidth. We could
probably make an attempt to filter out more modes from the common mode
list to avoid these issues, but it's likely that the driver already
lists suitable modes, meaning there is no point in adding the common
modes.
The common modes were initially added[0] to add modes to connectors with
a single bundled mode, so we shouldn't regress the original bug fix.
[0] https://bugzilla.gnome.org/show_bug.cgi?id=744544
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1232
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1824>
The intel DRM driver is known for not being able to handle multi head
setups when KMS modifiers are enabled, due to the implicitly selected
modifiers, while being more suitable for single head setups, cause
bandwidth issues when a certain number of monitor times resolution and
refresh rate is configured.
We don't yet support automatically finding a combination of modifiers
that work, and have because of this disabled KMS modifiers unless the
driver actually needs it.
Lets flip this configuration the other way around, changing the current
udev rule to decide wen to *disable* KMS modifier support, as it so that
only the Intel driver has this problem, while on the other hand, there
several drivers that requires modifiers to function at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
The input thread is in deep water doing the meta_is_*() check itself,
as that pokes the MetaMonitorManager managed by the main thread. Use
the getter from the MetaViewportInfo instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1793>
We need to pass this info from the main thread, as that pokes the
MetaMonitorManager underneath. Store it in the MetaViewportInfo
so that the input thread can use this information.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1793>
MetaInputSettings unref:ed the seat on destruction, but it never ref:ed
it on construction, meaning it "stole" the reference from the rightful
owner. Make MetaInputSettings less of a thief.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
XIQueryPointer allocates the button state mask that we were leaking in
some places. We need to manually free this, because there is no XI
function that would do this for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1728>
On Wayland MetaInputSettings is part of the input thread. Connecting
a GSettings binding to the default ClutterSettings could result in the
change notification being emitted on the input thread. This then could
end up triggering the same handler from two different threads at the
same time. In the case of the ClutterText layout cache it was attempting
to unref the same layout twice, leading to a crash.
This can be avoided by simply removing the GSettings bind. This does not
cause changes to this setting to be missed by ClutterSettings because it
itself already sets up a bind.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1696
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1776>
This eliminates the need for any render node or device nodes, thus can
be used without any graphics hardware available at all, or with a
graphics driver without any render node available.
The surfaceless mode currently requires EGL_KHR_no_config_context to
configure the initial EGL display.
This also means we can enable the native backend tests in CI, as it
should work without any additional privileges.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The new RecordVirtual API creates a virtual monitor, i.e. a region of
the stage that isn't backed by real monitor hardware. It's intended to
be used by e.g. network screens on active sessions, virtual remote
desktop screens when running headless, and scenarios like that.
A major difference between the current Record* API's is that
RecordVirtual relies on PipeWire itself to negotiate the refresh rate
and size, as it can't rely on any existing monitor, for those details.
This also means that the virtual monitor is not created until the stream
negotiation has finished and a virtual monitor resolution has been
determined.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The area source, window source, and monitor source, currently set up the
stream size up front, given the area, maximum allowed window size or
monitor resolution, but for to be introduced sources, the size will be
negotiated using PipeWire, instead of specified via the D-Bus API. This
commit changes the internal source API to allow for this. There are
currently no users of this new behaviour.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
There may be a race between the ability to turn stream relative input
coordinates and turning them into screen coordinates, due to the future
scenario where the entity backing a stream is created and managed ad-hoc
depending on PipeWire stream negotiations.
When an input event is sent during this time, drop it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The testing currently done is:
* Creating a virtual monitor succeeds and gets the right configuration
* Painting a few times results in the expected output
* Changing the content of the stage also changes the painted content
accordingly
* Destroying the virtual monitor works as expected
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This adds a test framework that makes it possible to compare the result
of painting a view against a reference image. Test reference as PNG
images are stored in src/tests/ref-tests/.
Reference images needs to be created for testing to be able to succeed.
Adding a test reference image is done using the
`MUTTER_REF_TEST_UPDATE` environment variable. See meta-ref-test.c for
details.
The image comparison code is largely based on the reference image test
framework in weston; see meta-ref-test.c for details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Virtual monitors are monitors that isn't backed by any monitor like
hardware. It would typically be backed by e.g. a remote desktop service,
or a network display.
It is currently only supported by the native backend, and whether the
X11 backend will ever see virtual monitors is an open question. This
rest of this commit message describes how it works under the native
backend.
Each virutal monitor consists of virtualized mode setting components:
* A virtual CRTC mode (MetaCrtcModeVirtual)
* A virtual CRTC (MetaCrtcVirtual)
* A virtual connector (MetaOutputVirtual)
In difference to the corresponding mode setting objects that represents
KMS objects, the virtual ones isn't directly tied to a MetaGpu, other
than the CoglFramebuffer being part of the GPU context of the primary
GPU, which is the case for all monitors no matter what GPU they are
connected to. Part of the reason for this is that a MetaGpu in practice
represents a mode setting device, and its CRTCs and outputs, are all
backed by real mode setting objects, while a virtual monitor is only
backed by a framebuffer that is tied to the primary GPU. Maybe this will
be reevaluated in the future, but since a virtual monitor is not tied to
any GPU currently, so is the case for the virtual mode setting objects.
The native rendering backend, including the cursor renderer, is adapted
to handle the situation where a CRTC does not have a GPU associated with
it; this in practice means that it e.g. will not try to upload HW cursor
buffers when the cursor is only on a virtual monitor. The same applies
to the native renderer, which is made to avoid creating
MetaOnscreenNative for views that are backed by virtual CRTCs, as well
as to avoid trying to mode set on such views.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
When rebuilding the monitors (e.g. during hotplug), make sure to detach
the disposed monitors from any outputs before creating the new monitors.
While this isn't currently needed, as outputs are too being recreated,
with the to be introduced virtual outputs that are created for virtual
monitors, this is not always the case anymore, as these virtual outputs
are not regenerated each time anything changes.
Prepare for this by making sure that cleaning up disposed monitors
detach themself properly from the outputs, so new ones can attach
themself to outputs without running into conflicts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
With this commit, it's possible to run mutter without being DRM master.
It's not yet possible to add virtual monitors, but one can for example
already add virtual input devices.
This currently doesn't try to hook up to any logind session, thus will
not have a real seat assigned. Currently it's hard coded to "seat0".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>