Instead of calling "init_onscreen()" on two different separate vtables
from the allocate() funtion, just have the CoglOnscreen sub types
themself implement allocate() and initialize in there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Thins means that e.g. MetaOnscreenNative now inherits CoglOnscreenEgl,
which inherits CoglOnscreen which inherits CoglFramebuffer, all being
the same GObject instance.
This makes it necessary to the one creating the onscreen to know what it
wants to create. For the X11 backend, the type of renderer (Xlib EGL or
GLX) determines the type, and for the native backend, it's currently
always MetaOnscreenNative.
The "winsys" vfunc entries related to onscreens hasn't been moved yet,
that will come later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
To get meta-renderer-native.c down to a bit more managable size, and to
isolate "onscreen" functionality from other (at least partly), move out
the things related to CoglOnscreen to meta-onscreen-native.[ch].
A couple of structs are moved to a new shared header file, as
abstracting those types (e.g. (primary, secondary) render devices) will
be dealt with later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The mutter naming convention for types and their instance variables is:
Type name:
[Namespace][BaseName][SubType]
Instance name:
[base_name]_[sub_type]
This means that e.g. CoglOnscreenGLX is renamed CoglOnscreenGlx, and
glx_onscreen is renamed onscreen_glx. This is in preparation for
GObjectification.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Makes sure that monitor specs which may be read from EDID data do not
contain characters that are invalid in XML. Makes it possible to restore
monitor configs of monitor models with characters such as '&' in them.
To make this change not break any tests, the sample monitor configs need
to be adjusted as well. Apostrophes don't strictly have to be escaped in
XML text elements. However, we now do escape the elements in
`<monitorspec>` specifically.
Closes: <https://gitlab.gnome.org/GNOME/mutter/-/issues/1011>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1685>
If the monitor configuration changed, even though the streamed monitor
didn't change, we'd still fail to continue streaming, as we failed to
update the stage watchers, meaning we wouldn't be notified about when
the stage views were painted.
Fix this by reattaching the stage watches, i.e. update the painted
signalling listeners to listen to the right views, when monitor changes
happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1691>
Make the API used more shared and better named.
meta_monitor_manager_on_hotplug() was renamed
meta_monitor_manager_reconfigure(), and meta_monitor_manager_reload()
was introduced to combine reading the current state and reconfiguring.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1689>
It was named "backend_native" and "backend" which is easily confused with
MetaBackendNative and MetaBackend which tends to have those names.
Prepare for introducing the usage of a MetaBackendNative and MetaBackend
pointers here by cleaning up the naming.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1689>
This adds a MetaKmsImplDevice backend using atomic drmMode* API in constrast to
non-atomic legacy drmMode* API used in MetaKmsImplDeviceSimple.
This has various behavioral differences worth noting, compared to the
simple backend:
* We can only commit once per CRTC per page flip.
This means that we can only update the cursor plane once. If a primary
plane composition missed a dead line, we cannot commit only a cursor
update that would be presented earlier.
* Partial success is not possible with the atomic backend.
Cursor planes may fail with the simple backend. This is not the case
with the atomic backend. This will instead later be handled using API
specific to the atomic backend, that will effectively translate into
TEST_ONLY commits.
For testing and debugging purposes, the environment variable
MUTTER_DEBUG_ENABLE_ATOMIC_KMS can be set to either 1 or 0 to
force-enable or force-disable atomic mode setting. Setting it to some
other value will cause mutter to abort().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/548
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
In order to reliably manage the reference count of the user data passed
to page flip listeners - being the stage view - make the ownership of
this data travel through the different objects that take responsibility
of the next step.
Initially this is the MetaKmsPageFlipListener that belongs to a
MetaKmsUpdate.
When a page flip is successfully queued, the ownership is transferred to
a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the
simple impl device, the MetaKmsPageFlipData is passed to
drmModePageFlip(), then returned back via the DRM event. In the future
atomic impl device, the MetaKmsPageFlipData is stored in a table, then
retrieved when DRM event are handled.
When the DRM events are handled, the page flip listener's interface
callbacks are invoked, and after that, the user data is freed using the
passed GDestroyNotify function, in the main context, the same as where
the interface callbacks were called.
When a page flip fails, the ownership is also transferred to a
MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page
flip data will be passed to the main context via a callback, where it
will discard the page flip, and free the user data using the provided
GDestroyNotify.
Note that this adds back a page flip listener type flag for telling the
KMS implementation whether to actively discard a page flip via the
interface, or just free the user data. Avoiding discarding via the
interface is needed for the direct scanout case, where we immediately
need to know the result in order to fall back to the composite pipeline
if the direct scanout failed. We do in fact also need active discard via
the interface paths, e.g. in the simple impl device when we're
asynchronously retrying a page flip, so replace the ad-hoc discard paths
in meta-renderer-native.c and replace them by not asking for no-discard
page flip error handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Suspending might have changed the CRTC configuration, turning some off,
some on, etc. We need to update our internal representation of this
state, so that we know how to reconfigure upon resuming, e.g. what CRTCs
to turn off again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Destroying an onscreen destroyes the gbm_surface, the gbm_bo's, and the
fb_id's. Doing this (drmModeRmFB() of the fb_id specifically), may on
some hw implicitly disable the CRTC of the plane that framebuffer was
assigned to. This would cause following atomic commit that attempts to
disable the CRTC to fail as disabling an already disabled CRTC is not
allowed.
It'd also mean we'd always disable the plane before having finished next
mode set, leaving it monitor content potentially empty when not really
necessary.
Solve this by keeping the CoglOnscreens (thus the gbm_surface, gbm_bo
and fb_id) alive until the following global mode set has completed, i.e.
the new state has been fully committed and applied.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This makes "power save" (i.e. when you make a monitor go into power save
mode, or make it come out of power save mode), a per device action when
turning on power saving (power save being set to 'off'), and implicitly
handled when turning off power saving (power save being set to 'on')
when doing a mode set.
This is needed as with atomic mode setting, the configuration of DPMS
(Display Power Management Signaling), is replaced by directly turning on
or off CRTCs, and via the CRTC drm properties. Thus in order to handle
both with a common API, make that API high level enough for both cases
being covered.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Before we received new gamma updates via D-Bus and posted the update to
KMS directly. This won't be possible with atomic KMS, since one can only
update the state of a CRTC once per cycle.
Thus, to handle this, when configured by D-Bus, only cache the value,
and mark it as invalid. The next frame, the native renderer will pick
up the newly cached gamma value and configure the CRTCs accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
We cannot switch DPMS state to 'on' first, then mode set later, when
using atomic KMS. So when we're turning it on, just let the eventual
mode set handle DPMS too.
When switching DPMS to 'off', do it directly, synchronously, both by
setting the DPMS state and switching off CRTCs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
