This uses the ref test infrastructure inside the cursor tests screen
cast client, and verifies the content on the screen cast matches the
content of the compositor, both when using the 'embedded' cursor mode,
and the 'metadata' cursor mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
It doesn't contain anything screen cast specific, except the
XDG_RUNTIME_DIR, so make it usable from elsewhere. While at it, prepare
it for being able to run the glib test functionality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
This also avoids loosing precision since the float won't be casted to an
int before being used to configure the test output.
Currently there is only one test that expects the scale to be calculated
dynamically, all the other always assume scale ending up being 1.0
unless explicitly configured in some way.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
Only actively test MemFd, and don't ever ask for or expect MemPtr, since
we don't support those anyway. Also, for convenience, ask the buffers to
be automatically mmap:ed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
We create the cursor view data when we update the cursor, but allow the
texture to be realized earlier than that. The texture change listener
invalidates the hw cursor validity state, but since it's initialized to
invalid, the hardware cursor will still be correctly handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
This makes the overlay code work which is notably used for screen
sharing and recording if the client doesn't support meta-data cursors.
[jadahl] Changed the approach the way coordinates are scaled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
It took a MetaTestClient, which wasn't used. To allow it be used for windows
that doesn't come from a MetaTestClient, remove the MetaTestClient
namespace, and update the callers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
This adds wl_seat and wl_pointer boilerplate, and a pointer-entered
signal on the surface helper struct. It's intended to be used by a
future cursor test case client.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3859>
Following previous commit, rename _clutter_paint_volume_init_static()
to clutter_paint_volume_init_from_actor(), and also
_clutter_paint_volume_copy_static() to
clutter_paint_volume_init_from_paint_volume().
Make clutter_paint_volume_init_from_paint_volume() follow the dst/src
semantic in its arguments, which also allows removing
_clutter_paint_volume_set_from_volume() which is exactly the same now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
And change clutter_paint_volume_free() to always free the paint volume.
Remove all calls to clutter_paint_volume_free() on static variables.
Having to call a free function on a static variable always seemed a bit
odd, and this genuinely confuses Coverity (and me).
Coverity CID: #1505838
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
As far as I can see this doesn't happen in practice, but theoretically
the uninitialized values can be used if:
1. `did_placement` is TRUE
2. `flags` contains both `META_MOVE_RESIZE_RESIZE_ACTION` and
also `META_MOVE_RESIZE_MOVE_ACTION`
3. `!meta_window_is_tied_to_drag (window)` is FALSE
In that case, the `frame_rect` variable (with uninitialized values) is
passed to `unconstrained_rect`, then passed to `constrained_rect`,
then finally the (uninitialized) X and Y values are read in the
`if (did_placement)` branch.
This is probably a regression from 3047b2ce261. I don't know if this is
the appropriate fix.
Coverity CID: #1511378
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
As they are now shared between GL3 and GLES3 texture driver, there is no
need anymore for having them in a separate header and included.
Cleanup the names of the functions while doing so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4163>
Abstract away the common bits between GL3 and GLES2 TextureDriver
implementations by sharing the common bits in a parent class.
Ideally, we would move the various vfuncs that are GL specific from the
abstract TextureDriver type but that can be done at a later stage once
there is actual work on adding a Vulkan driver.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4163>
As they make more sense there. Maybe we could have a common
OpenGLTextureDriver
that would share the common texture_2d_* vfuncs but that can be done
later.
By moving those vfuncs to the TextureDriver, we can get rid of the
texutre_2d
nop driver implementations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4163>
