Fullscreen X11 windows that attempt to change the resolution on Wayland
use a surface viewport to achieve this without affecting the resolution
of the display. This however also means that pointer events will be
delivered in the display coordinates while the code handling the window
frame is not aware of any such viewport scaling. So a right click
outside of the area corresponding to the new resolution will not be
considered to be on the client area. And since the only area that is
ignored when determining whether to perform the right click action, such
as opening the context menu, is the client area, this will result in the
action being performed, despite happening on the (scaled) client area.
While it would be possible to scale the event coordinates so that
get_control() correctly determines the frame element the cursor is on,
viewport scaling only affects fullscreen windows. Since fullscreen
windows have no frame, we can always assume that if the window gets
delivered an event for a fullscreen window, it is on the client area
without doing any additional calculations.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1592
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1661>
We remove pending pings when unmanaging a window, but currently
don't prevent new pings to be scheduled after that.
The previous commit fixed a code path where this did indeed happen,
but as the result of gnome-shell trying to attach a Clutter actor
to a non-existent window actor is pretty bad, also guard can_ping()
against being called for an unmanaging window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676>
This seems to have been the default in the past, but was (accidentally?) modified
by 8adab0275.
For GNOME 40, we'll be returning to our root with horizontal workspaces, so instead
of overriding it in GNOME Shell side, change the default back to what it once was.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1684>
We'll have two persistent client connections alive for the whole test,
one X11 client, and one Wayland client. So in order to be able to set up
the async waiter, do so after setting up the X11 client, as after that
we know we'll have a MetaX11Display ready to use.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1681>
One for the public channel, and one for the private maintainance
channel. Use the public one for test clients, otherwise tests become
flaky, and the private one for MetaX11Display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1681>
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>
Before each frame is maybe redrawn, push any new cursor KMS state to the
pending update. It'll then either be posted during the next page flip,
or when the same frame finishes, in case nothing was redrawn.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This makes it possible to post a symbolic page flip and frame callback,
meant to be used by immediate symbolic page flip reply when emulating
cursor plane changes using legacy drmMode* functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
In constrast to notify_presented(), notify_ready() also returns the
state machine to the idle state, but without providing new frame
information, as no frame was actually presented.
This will happen for example with the simple KMS impl backend will do a
cursor movement, which will trigger a symbolic "page flip" reply in
order to emulate atomic KMS behavior. When this happen, we should just
try to reschedule again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Don't mode set each CRTC in separate KMS updates, as reconfiguring one
CRTC might cause other CRTCs to be implicitly reset thus as well,
causing KMS return EBUSY if using atomic modesetting.
Prepare for this by compositing each CRTC first including adding steps
to the KMS update, but wait until all views has rendered at least once
before posting the initial update. After this each CRTC is posted
separately.
Using EGLStreams instead of normal page flipping seems to fail when
doing this though, so handle that the old way for the EGLStream case,
i.e. eglSwapBuffers() -> mode set with dumb buffer -> eglStream
"acquire" (resulting in page flip under the hood).
For this we also introduce a new error code so that we don't use client
buffers when doing mode sets, which could accidentally configure the
CRTC in a way that is incompatible with the primary plane buffers.
Do the same also when we're in power save mode, to only have one special
case path for this scenario in the regular swap-buffer path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of setting the frame result in the most generic layer, have the
backends do it themselves. This is necessary to communicate that a
swap-buffer call didn't really succeed completely to present the swapped
buffer, e.g. errors from KMS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This argument is intended to be used by clutter to be able to
communicate with the onscreen backend, that happens to be the native
backend. It will be used to pass a ClutterFrame pointer, where the
result of page flips, mode sets etc can be communicated whenever it is
available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
ClutterFrame aims to carry information valid during dispatching a frame.
A frame may or may not include redrawing, but will always end with a
result.
A asynchronous page flip, for example, will result in a
CLUTTER_FRAME_RESULT_PENDING_PRESENTED, while a frame that only
dispatched events etc will result in CLUTTER_FRAME_RESULT_IDLE. Instead
of this being implicit, make the ClutterStageWindow implementation
handle this itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
The way drm events are handled depends on whether we're using atomic or
not. Lets move the handling to the implementation, so that later the
atomic backend can handle the event they it need to.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If we reassign e.g. a cursor plane twice before it's updated, we need to
make sure the 'fb-unchanged' flag is correctly handled, so that if we
changed the fb first, then updated the assignment again only changing
the position, the new assignment should not be flagged with
fb-unchanged.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
When we e.g. try to post an direct client buffer scanout update, it
might arbitrarily fail; when this happen we still will want to post the
rest of the update when we try again after having composited the primary
plane. To do this, add a way to preserve the metadata of an update if it
failed, only dropping the failed plane assignments. This involves
unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary
plane can be assigned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Sealing is a one way operation, but in the next commit, the "seal" will
be broken, so to avoid missusing the "seal" terminology, rename related
methods and variables to use the term "lock" instead. E.g.
meta_update_is_sealed() is now meta_update_is_locked().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If a modeset is pending, it's likely that the cursor update will not
work; thus, wait with updating the cursor so that it's applied together
with the mode set update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Something might want to affect the next update that is going to be
posted, but without posting it immediately. For example, changing the
cursor might need to wait for mode setting. Make it possible to get
feedback from posting the update, in order to gracefully handle any
errors.
Note, the API for notifiying about results take out the result listener
from the update, and notifies them in an open coded for loop. The reason
for this is that in the next commit we'll sometimes reuse updates, and
we only want notify about the results once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
