Stop taking a ClutterEvent and pass the essentials here (x/y/evtime),
we don't have a ClutterEvent handy in all places that we call this
API, and it feels awkward to create one just for calling this vmethod.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
It is a bit backwards that events contain information about
the stage they are being handled by. It makes more sense to
specify in the ClutterEvent handling entrypoint the stage
that will handle the event.
As a first step, add this ClutterStage argument, even though
the information is still carried through the event in order to
keep satisfying calls to the getter function.
This entrypoint has been also renamed to clutter_stage_handle_event(),
so that its ownership/namespace is clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Nowadays, all our MapNotify event handling happens already prior to
the MetaCompositorX11 handling of XEvents. It does not make sense to
channel these events again through the backend, at best all it could
lead to is double handling of the same events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
These "features" are somewhat less featured, it's becoming too ugly
to handle all of them with a single API call. The clear outlier are
buttons, so move them to a separate function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3005>
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>
Implement importing of multi-plane formats. For now, only support
importing planes individually using "sub-formats". This is the most
commonly driver-supported approach in the moment, used by other
Wayland compositors as well.
In the future we will additionally want to support importing the formats
directly and let the drivers handle conversion internally.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
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>
To be able to later support more complex YUV formats, we need to make
sure that MetaShapedTexture (the one who will actually render the
texture) can use the MetaMultiTexture class.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Daniel van Vugt <daniel.van.vugt@canonical.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
In future commits, we want to be able to handle more complex textures,
such as video frames which are encoded in a YUV-pixel format and have
multiple planes (which each map to a separate texture).
To accomplish this, we introduce a new object `MetaMultiTexture`: this
object can deal with more complex formats by handling multiple
`CoglTexture`s.
It supports shaders for pixel format conversion from YUV to RGBA, as
well as blending. While custom bleding is currently only required for
YUV formats, we also implement it for RGB ones. This allows us to
simplify code in other places and will be needed in the future once
we want to support blending between different color spaces.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
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>
It returns non-0 if there are any hints in the WM_NORMAL_HINTS
property, 0 if there are none.
Fixes the mouse cursor changing to the resize shape over the decorations
of non-resizable windows.
Fixes: c7b3d8c607 ("frames: Push error traps around various X11 calls")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3096>
With libdecor, window moving/resizing only works with
the pointer, not with touch.
The meta_wayland_pointer_can_grab_surface checks for subsurfaces,
but the meta_wayland_touch_find_grab_sequence does not.
Add a similar subsurface check to
meta_wayland_touch_find_grab_sequence.
Closes: GNOME/mutter#2872
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3125>
Removing duplication, making it easier to add new formats and ensuring
that the native backend and Wayland clients can use the same formats.
Also improve related build files so the Wayland backend can be build
without the native backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
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>
The default cogl blend string is
`RGBA = ADD (SRC_COLOR, DST_COLOR*(1-SRC_COLOR[A]))` which is alpha
blending with premult fragment results. We do not clear the src
framebuffer and even if we did set alpha to 1 in the src fb, the
resulting alpha would be 1 and we want to check the alpha of the
fragment color.
Just turn off any kind of blending instead and write out the fragment
color to the fb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
To obtain a float between 0 and 1 we have to devide the integer by the
highest possible value instead of the number of values.
Fixes off by one errors in the tests on some hardware/driver
combinations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
So we can properly handle matching DRM and WL_SHM formats in a unified
manner.
Add extensive testing between these and existing pre-multiplied alpha
formats, i.e. all formats we support on Wayland.
Note that unfortunately for some format combinations the value in the
alpha channel is not cleared as expected, likely because of fast-paths
in Cogl. If both source and destination format is opaque, it always
works, however. This thereby includes all cases where they are the same.
Co-Authored-By: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
