queue_update() in a previous iteration was called in two situations:
* A page flip was already pending, meaning if we would commit an
update, it'd fail with EBUSY.
* A update was marked as "always-defer" meaning it should only be
processed from the deadline callback (would there be one). These were
used for cursor-only updates.
In the latter, we had to arm the deadline timer when queuing a new
update, if it wasn't armed already, while in the former, we would
currently idle, waiting for the page flip callback. At that callback
would the deadline timer be re-armed again.
Since we're only handling the former now, we'll never need to arm the
timer again, so remove code doing so. The code removed were never
actually executed anymore, after the "always-defer" flag on updates was
removed.
Fixes: 27ed069766 ("kms/impl-device: Add deadline based KMS commit scheduling")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2940
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3150>
Primary plane updates were forgetting to do this in OnscreenNative, but
rather than do it for each post there we should simply do it for each
post.
This fixes cursor stutter in the fallback path (not using deadline timers)
where needs_flush_crtcs would remain populated but CRTC_NEEDS_FLUSH would
never be emitted, because handle_flush hadn't been called for the last
post.
This is safe as the current use of scheduled flushing is only for cursor
updates, and since cursor updates happen on the same thread as processing,
and due to the fact that we always use the most up to date cursor position
when flushing, we never risk leaving an old cursor state unflushed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3138>
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>
When we see a mode set, the cursor manager will update all the cursor
planes so they are set correctly as part of the mode set. KMS updates
are always per-device, and what was wrong was that it didn't filter out
CRTCs on devices that wasn't part of the mode set.
Reported-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3130>
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>
We can schedule an update from the cursor manager, but that doesn't mean
there will be an actual plane assignment changed at the time of the
update processing, since for example we might have "touched" a CRTC, but
already left it before the processing started, meaning we have nothing
to change after all.
Add a test case that checks that this works properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This removes the old hardware cursor management code and outsources it
to MetaKmsCursorManager. What the native cursor renderer still does,
however, is the preprocessing i.e. rotating/scaling cursor that wouldn't
otherwise be fit for a cursor plane.
The cursor DRM buffers are instead of being per cursor sprite now per
CRTC, meaning we don't need to stop doing hardware cursors if part of
the cursor is on an output that doesn't support it. This is why the
whole scale/transform code changed from being per GPU to per CRTC.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
If we turn of a CRTC, we might have invalidated the cursor manager for
the same CRTC, but that should not mean a cursor plane is assigned when
turning off the CRTC.
Add a test case for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This new manager object intends to take over management of the cursor
plane from the native cursor renderer. It's API is intended to be used
from the main thread, except for the _in_input() function, but mainly
operates in the KMS context, i.e. the KMS thread.
It makes use of an "update filter" that is called before each
MetaKmsUpdate is turned into a atomic KMS commit or a set of legacy
drmMode*() API calls. When the cursor position has been invalidated,
it'll assign the cursor plane in the filter callback, using an as up to
date as possible pointer position as the source for the cursor plane
position.
Cursor updates from the input thread schedules updates for the affected
CRTCs which will cause the filter to be run, potentially for cursor-only
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This adds some plumbing to get the "default" paint flags for regular
stage painting, where one either wants to paint the overlay, or not.
If inhibited, the 'no-cursors' paint flag is used, otherwise the 'none'
flag. This will be used to allow having a per stage view hw cursor
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This makes it possible to post KMS updates that will always defer until
just before the scanout deadline. This is useful to allow queuing cursor
updates where we don't want to post them to KMS immediately, but rather
wait until as late as possible to get lower latency.
We cannot delay primary plane compositions however, and this is due to
how the kernel may prioritize GPU work - not until a pipeline gets
attached to a atomic commit will it in some drivers get bumped to high
priority. This means we still need to post any update that depends on
OpenGL pipelines as soon as possible.
To avoid working on compositing, then getting stomped on the feet by the
deadline scheduler, the deadline timer is disarmed whenever there is a
frame currently being painted. This will still allow new cursor updates
to arrive during composition, but will delay the actual KMS commit until
the primary plane update has been posted.
Still, even for cursor-only we still need higher than default timing
capabilities, thus the deadline scheduler depends on the KMS thread
getting real-time scheduling priority. When the thread isn't realtime
scheduled, the KMS thread instead asks the main thread to "flush" the
commit as part of the regular frame update. A flushing update means one
that isn't set to always defer and has a latching CRTC.
The verbose KMS debug logging makes the processing take too long, making
us more likely to miss the deadline. Avoid this by increasing the
evasion length when debug logging is enabled. Not the best, but better
than changing the behavior completely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This is helpful when we add callbacks that should be dispatched in the
KMS impl thread.
This invalidates an assumption about callbacks not being in the impl
context, so some asserts for that are also removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This signal is emitted before terminating the thread, but also when
resetting the thread type. This is to allow thread implementations to
make sure they have no stale pending callbacks to any old main contexts.
This commit "terminates" the impl thread even if there is no actual
thread; this is to trigger the "reset" signal, also when switching from
a user thread to a kernel thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means we can add COGL_TRACE*() instrumentation that is grouped
correctly in sysprof. If kernel threading is enabled, they will end up
in a "Compositor (KMS thread)" group (ignoring translations).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Real time scheduling is needed for better control of when we commit
updates to the kernel, so add a property to MetaThread that, if the
thread implementation uses a kernel thread and not a user thread, RTKit
is asked to make the thread real time scheduled using the maximum
priority allowed.
Currently RTKit doesn't support the GetAll() D-Bus properties method, so
some fall back code is added, as GDBusProxy depends on GetAll() working
to make the cached properties up to date. Once
https://github.com/heftig/rtkit/pull/30 lands and becomes widely
available in distributions, the work around can be dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Also add an API to inhibit the kernel thread from being used, and make
MetaRenderDeviceEglStream inhibit the kernel thread from being used if
it's active.
The reason for this is that the MetaRenderDeviceEGlStream is used when
using EGLStreams instead of KMS for page flipping. This means the actual
page flipping happens as a side effect of using EGL/OpenGL, which can't
easily be done off thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This will be necessary in order to default to 'kernel' and then switch
to 'user' if the thread instance can no longer be properly multi
threaded.
To avoid having the same thread impl creating and destroying
GMainContext's, this also means always creating a GMainContext for the
thread-impl. When running in user-thread mode, the GMainContext is
wrapped in a wrapper source and dispatched as part of the real main
thread GMainContext, and when in kernel-thread mode, it runs
independently in the dedicated thread.
This has the consequence that the wrapper source will always have the
priority of the highest impl context GSource, but only after it has
dispatched once. Would we need it earlier than that, we either need a
way to introspect existing sources in a GMainContext and their
priorities, or manually track known sources in MetaThreadImpl.
The wrapper source will never be below 0, as that'd mean it could reach
INT_MAX priority if it had no more sources attached to it, meaning it'd
never be dispatched again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While doing this, rename the old synchronous functions to more clearly
communicate that they expect to actually process the update during the
call, not just post it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While the default when passing NULL will be the main context of the main
thread, make it possible to specify another main context, so that
result handlers can be invoked on the right thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Callbacks could be queued to be invoked either on the impl side or the
main thread side of the thread; change this to take a GMainContext,
which effectively means a callback can be queued to be invoked on any
thread that has a GMainLoop running on its own GMainContext.
Flushing is made to handle flushing callbacks synchronously on all
threads. This works by keeping a hash table of queued callbacks per
thread (GMainContext); when flushing (from the main thread), callbacks
on the main thread context is flushed, followed by synchronization with
all the other threads.
meta_thread_flush_callbacks() is changed to no longer return the number
of dispatched callbacks; it becomes much harder when there are N queues
spread across multiple threads. Since it wasn't used for anything, just
drop the counting, making life slightly easier.
Feedback to thread tasks are however always queued on the callers
thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This uses the queue that was introduced when migrating impl task
management from MetaThread to MetaThreadImpl, with the exception that
it's now fully used as an actual queue. It now has a GSource that sits
on the right GMainContext that is dispatched whenever there are tasks to
execute.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It's the impl side that wants to add impl side idle sources, or fd
sources, etc, so make it part of MetaThreadImpl.
This changes things to be GAsyncQueue based. While things are still
technically single threaded, the GAsyncQueue type is used as later we'll
introduce queuing tasks asynchronously, then eventually queuing across
thread barriers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It currently does exactly what MetaKms and MetaKmsImpl did regarding the
context separation, which is to isolate what may eventually run on a KMS
thread into a separate unit. It works somewhat like a "user thread",
i.e. not a real thread, but will eventually learn how to spawn a
"kernel thread", but provide the same API from the outside.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Remote desktop version 2 added a new method ConnectToEIS .
ConnectToEIS allows clients to requests a file descriptor from the
compositor which can then be used directly from libei.
Once established, the communication between compositor and application
is direct, without the need to go through the portal process(es).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
When a relative pointer motion gets constrained (e.g. a monitor edge or
barrier), save the constrained relative motion delta too.
This will later be used to send the remaining motion delta to input
capture clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Adding a barrier and later enabling the input capture session will
create MetaBarrier instances for each added input capture barrier.
The barriers are created as "sticky" which means that when a pointer
hits the barrier, it'll stick to the point of entry, until it's
released.
The input capture session is also turned into a state machine with
explicit state, to more easily track things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This allows for a sticky barrier to hold the pointer until it is
released, but the owner of the barrier doesn't need a barrier event to
release it. It will be used to implement input capturing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
A sticky barrier means that a pointer in motion intersecting a barrier
doesn't move once having hit it. The intention with this is to allow an
input capture clients to continue a motion once a barrier is hit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This API aims to provide a way for users to capture input devices under
certain conditions, for example when a pointer crosses a specified
barrier.
So far only part of the API is implemented, specifially the session
management as well as zone advertisement, where a zone refers to a
region in the compositor which edges will eventually be made available
for barrier placement.
So far the remote access handle is created while the session is enable,
despite the input capturing isn't actually active yet. This will change
in the future once it can actually become active.
v2: Remove absolute/relative pointer, keep only pointer (ofourdan)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Previously, restarting mutter in an X11 session resulted in
the previously set color temperature not being applied.
Fix that by applying the color temperature right after
the org.gnome.SettingsDaemon.Color proxy has been created.
Furthermore, only call `update_all_gamma()` from `on_gsd_color_ready()`
when the temperature has actually changed. Otherwise there is no need
since the current temperature has already been (or will soon be) applied
to all ready color devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3008>
In remote desktop sessions, streams can be created and destroyed
on-the-fly.
If a stream is gone, it is not necessarily an error.
So, don't treat that situation like an erroneous one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2911>
The previous logic didn't work correctly at least when priority-based
preeption wasn't supported by the DRM driver, such as in the case
of amdgpu. The call to glGetQueryObjecti64v would block on client
work which is already in progress (most likely for the next frame)
and delay notifying the ClutterFrameClock about presentation.
Conveniently, the Wayland transactions mechanism guarantees that all
fences of a dma-buf buffer are signalled before the buffer is
included in a frame, which means that dma-buf buffers are ready for
presentation when being directly scanned-out.
Direct scanout is only supported for dma-buf buffers too, which means
that all buffers going through direct scanout are effectively ready
and require no GPU rendering before presentation.
Assuming zero rendering time for dma-buf buffers going through direct
scanout simplifies the code and removes the need for
glGetQueryObjecti64v, thus avoiding the aforementioned issue where it
could block for longer than expected.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2766
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3080>
This means initializing the pointer position in MetaSeatImpl
synchronously too, otherwise it's not guaranteed querying the seat state
will result in the expected position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3071>
I have a monitor which can report two preferred modes: 5120x1440@240
and 3840x1080@60. Since they are enumerated in this order by KMS,
init_output_modes would end up using 3840x1080@60 (and it was impossible
to select any 5120x1440 mode in the GNOME display settings).
Fix this by using meta_kms_connector_get_preferred_mode, which returns
the first KMS mode with DRM_MODE_TYPE_PREFERRED.
v2:
* Use meta_kms_connector_get_preferred_mode. (Jonas Ådahl)
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3055>
This will consist of device-added events, meaning before init finishes,
we can derive some state that depends on the set of input devices
available on startup, such as cursor visibility.
This avoids cursor visibility switching between hidden and visibility
during startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This opens up for a possibility to handle initial events (devices
discovered on startup) during initialization, meaning we can figure out
a more correct initial state that depends on available input devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This is different from "warping" as it doesn't necessarily result in a
pointer motion event. This can be helpful during initializing so we can
avoid faked pointer events that would otherwise need to be special cased
to not appear as actual pointer movements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
