Some clients - notably the Gstreamer vapostproc element when using Intel
GPUs - only support BGRA, not BGRx. We already assume that we can
support this format for window screen casts, and even in case of failure
we now have a re-negotiation fallback in place. Thus it's pretty safe to
support it for all screen cast types.
The possible duplication in case of window screen casts doesn't seem to
be a problem for either Pipewire or existing clients like OBS.
Note that the implementation lays the foundation to make it easy to add
more formats in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3617>
This change adds modifier-aware screencasting support to Mutter.
Implicit modifier support is kept for backward compatibility and the
code fallbacks to implicit modifiers in case any new functionality added
for explicit modifier support fails.
The advertised modifiers are retrieved by a call to
eglQueryDmaBufModifiersEXT() function. The "external only" modifiers are
excluded as Mutter uses the buffers created with the explicit modifiers
as renderbuffers. Support for implicit modifiers is checked with a test
allocation since there are drivers that do not support them.
This change also removes various implicit modifier support checks that
disable DMA-BUF screen casting support globally as they are no longer
needed. DMA-BUF support for screencasting is determined by the available
formats and modifiers case-by-case now.
It also effectively enables DMA-BUF screencasting on NVIDIA hardware as
well since GBM buffer objects with linear modifiers are no longer used
by default to create a renderbuffer object for screencasting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3537>
After negotiation of DMABUF transport mutter will silently allocate SHM
buffers if the allocation in the add_buffer callback fails. It's cleaner
to renegotiate the supported formats without announcing DMABUF
capabilities in this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2557>
To fixate the format or renegotiate after a DMABUF allocation failed we
need to rebuild the EnumFormat params.
The function meta_screen_cast_query_modifiers will return false if no
modifiers are supported, thouse we can drop the check and remove the
macro guard.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2557>
Track where we are in terms of the paint cycle. Do this through an
enumeration that is passed through the paint vfuncs of screencast
sources.
Right now, this information is not used by any one of the sources,
but next patch will use it to prevent blitting when detached from
the paint cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3406>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
1. Centralize stride calculation in one function.
2. For dmabufs query the stride instead of assuming a certain value.
3. For system memory buffers use the pixel format to calculate the
stride.
4. Stop negotiating `SPA_PARAM_BUFFERS_size` and
`SPA_PARAM_BUFFERS_stride`.
2. fixes an actual bug where we reported wrong max buffer sizes,
resulting in crashes in Gstreamer when doing area screencasts on AMD
GPUs.
The reasoning for 4. is that the values were possibly wrong for
dmabufs as the negotiation happens before we create any buffers.
Further more neither Mutter nor the common consumers required it.
The later either ignore the values (OBS), always accept (gstpipewiresrc)
them or calculate the exact same possibly wrong values (libwebrtc).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6747
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3311>
The min was set to the max, and the max was set to the min, making
virtual monitors refresh rate very very slow.
Fixes: 215b91a2e6 ("screen-cast/src: Consider preferred format for stream")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3239>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
When creating a new stream, check if the preferred format is
different from the default (COGL_PIXEL_FORMAT_BGRX_8888). If
it is, then also include it in the list of potential formats
for the stream.
COGL_PIXEL_FORMAT_BGRX_8888 is still passed around as it's
both the default, and the fallback for when things go wrong.
When creating buffers, use the negotiated SPA format instead
of a hardcoded value. We leave it to PipeWire to figure out
what's the best format, since clients may not support the
preferred format of the stream.
Due to how chaotic things got, this commit also cleans up
the create_pipewire_stream() to use an auxiliary array of
SPA formats, which is then iterated on in order to generate
the format pods.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
The DMA buffer paths vs MemFd paths differ slightly in when content is
recorded. This was in some places done by trying to record but bail if
the dequeued buffer had the wrong type. This is problematic for two
reasons: we'd update the timestamp even if we refused to record, making
the follow-up attempt fail, and we'd dequeue and queue buffers that
didn't get any content, meaning the receiving end would see empty
buffers potentially with only cursor updates.
Fix this by keeping track if a stream is DMA buffer able or not, and
don't attempt to record at all in the places we would previously require
DMA buffers. This avoids both issues: we don't dequeue/queue pw_buffers
that we refuse to record to, and we won't update the recorded timestamp
when we didn't intend to record to begin with.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2783
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2987>
When a stream source subclass asks for a DMA-BUF only frame record,
it is legitimate to return FALSE in do_record_frame() - meaning that
a frame was not recorded - but not return an error - meaning nothing
actually failed.
This avoids spamming the journal with warnings on a legitimate case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
Add meta_screen_cast_stream_src_maybe_record_frame_with_timestamp()
which operates on arbitrary timestamps; and make the current function
meta_screen_cast_stream_src_maybe_record_frame() just call into the
new variant, passing g_get_monotonic_time() as the timestamp.
This will be useful later we start using the target timestamp of the
frame for screencasting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
This change will export the damaged regions (when available) out
to the pipewire client. This change is currently specific to
virtual streams only (where I was able to test the change) and
maintains the current behavior for other screencast stream types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
Streams are generally recoverable by the client and errors may happen
e.g. on negotiation failures. Right now we close the stream and
corresponding session, which is neither necessary nor expected by
clients.
Just disable the stream instead and let clients handle things as they
seem fit. This allows clients to e.g. try several Gstreamer pipelines
with limited caps on a single stream.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2850>
The fields of 'priv->video_format.max_framerate' are all of type
uint32_t. Multiplying by G_USEC_PER_SEC can overflow, and equally,
dividing a large numerical type by uint32_t can err too.
Since the variable holding the result is int64_t, cast all uint32_t
fields to int64_t before doing any maths on it.
Spotted while trying to investigating an issue with framerates on
HDMI screencasts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2762>
meta_screen_cast_stream_src_set_cursor_sprite_metadata() receives
the cursor sprite, position, and scale, and with that it downloads
the cursor sprite by drawing it into a separate framebuffer, then
calls cogl_framebuffer_read_pixels() in it - this is the offscren
path that is very common when using screen capturing applications
such as OBS Studio.
There's a sneaky issue in this code path though: the 'scale' value
is a float. The cursor size is then determined by multiplying the
sprite width and height - two integer variables - by scale, and
this relies on standard float-to-int conversions. This is problematic
as sometimes the rounded values disagree with what is expected by
cogl_framebuffer_read_pixels(). If the packing of either the cursor
width or height is off by one, glReadPixels() will try to write into
off bounds, which crashes.
This can be reproduced by enabling fractional scaling, setting a 150%
zoom level, on a 4K screen, and opening any commit with an image diff
in gitlab.gnome.org, all while screencasting. When hovering the new
image, the cursor sprite will be such that it triggers this code path,
and reproduces this issue.
Fix this by always ceiling the cursor sprite sizes.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2542
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2736>
With this header we can set a flag to signal that the whole buffer is
corrupt and should be ignored. With this we can cater to all cases:
* Window buffer fine, but cursor broken:
Use the spa_meta_cursor properties like id or offset accordingly
* Window buffer broken, but cursor fine:
Use the chunk flags
* Both are broken / the dequeued buffer is not usable
Use the spa_meta_header flag
Additionally clients can now check if a buffer contains spa_meta_header
data and can thus only check for the new or the old behaviour.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2516>
PipeWire supports flags to signal a corrupted buffer. We should use the
flag SPA_CHUNK_FLAG_CORRUPTED for `chunk->flags` instead of setting
`chunk->size = 0` since the size isn't well defined for arbitrary dmabufs
and should be set to 0.
Sadly clients like obs are using a chunk size of 0 to decide if a buffer
should be imported. Thus we should offer both until clients are using
the flag.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2323>
If the remote desktop service emits absolute input events (e.g. absolute
pointer events) before the stream has started streaming, we don't have a
virtual monitor, as the size has not been negotiated yet. When this
happens, just drop the event. Remote desktop services should probably
make sure not to send events before the streaming has started, but them
doing so anyway shouldn't trigger a crash, which would be the case
otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
Keep the virtual monitor around if it's being resized. This reduces the
number of unnecessary object rebuilding that happen during monitor
rebuilding.
This changes finalize() vfunc into a dispose() vfunc in the abstract
stream source object implementation, as it needs the abstract stream
source object to close the stream early, so that various signal
listeners get disconnected early.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1904
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
Add some debug logging that allows checking whether we're using DMA
buffers for screencasting or system memory buffers. This can be useful
for debugging screencasting performance and CPU usage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2256>
