For those using context from the application which
would be the embedded video case, if the frame callback
is entering at the same time as window is finalizing,
a wayland proxy object would be destroyed twice, leading
the refcout less than zero in the second time, it can
throw an abort() in wayland.
For those top window case, which as a directly connection
to the compositor, they can stop the message queue then
the frame callback won't happen at the same time as the
window is finalizing. It doesn't think it would bother
them about this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1883>
We were doing our initial "empty" commit on the subsurface instead of the
toplevel surface. As an incidence, we should not have received a configure
event ever, not just on mutter. This fixes the following warning when using
mutter compositor (aka gnome-shell):
waylandsink wlwindow.c:304:gst_wl_window_new_toplevel: The compositor did not send configure event.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2299>
This (so-far) Linux- and FreeBSD-only API lets users create file
descriptors purely in memory, without any backing file on the filesystem
and the race condition which could ensue when unlink()ing it.
It also allows seals to be placed on the file, ensuring to every other
process that we won’t be allowed to shrink the contents, potentially
causing a SIGBUS when they try reading it.
This patch is best viewed with the -w option of git log -p.
It is an almost exact copy of Wayland commit
6908c8c85a2e33e5654f64a55cd4f847bf385cae, see
https://gitlab.freedesktop.org/wayland/wayland/merge_requests/4
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1577>
"waylandsink: use GstMemory instead of GstBuffer for cache lookup"
changes the cache key to GstMemory, but the cached data still needs
a pointer to the GstBuffer to control the buffer lifecycle.
If the GstMemory used as the cache key moves from one GstBuffer to
another, the pointer in the cached data will be out-of-date.
Update the current GstBuffer pointer for each frame so that it always
represents the currently in use (from attach to release) GstBuffer
for each wl_buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1473>
The GstMemory objects contained in a GstBuffer could be replaced
by an upstream element, which would break the association beteen
the GstBuffer and the wayland wl_buffer, make the cache lookup
results incorrect.
This patch changes the cache lookup to use the first GstMemory
in a buffer instead. For multi-plane buffers, this assumes that
all of the GstMemory(s) will always be moved together as a set,
and that the same (first) GstMemory isn't used with different
combinations of other GstMemory(s).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1401>
Instead of attaching a single wayland wl_buffer to each GStBuffer as qdata,
keep a separate cache for each display.
A unique wl_buffer and associated metadata is created for each display.
This allows for sharing of GstBuffer objects between multiple
displays, such as when using tee elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1401>
When a pipeline is stopped (actually when the waylandsink element
state changes from PAUSED to READY) the video surface is cleared, but
the opaque black surface behind is not. Fix this by actually clearing
both surfaces.
xdg_shell fullscreen mode doesn't work for committing
xdg_surface without configure acknowledgement.
In addition, we can't set different surface setting from
acknowledged config in this mode.
It cleans up videoFormat by combining the wl_shm_formats and
drm_formats into a single table that represents the same format.
In addition, it adds NV61 format to the waylandsink.
This reverts commit 68fa80e831.
Some wayland servers, especially weston, only expect empty input
region as a request to disable input.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Use a timeout to limit that amount of time we wait after the compositor
for the initial configure event. Compositor are support to emit a
configure event before any wl_buffer can be attached. The problem is
that Weston strongly enforce this, while gnome-shell simply does not
emit such an event.
When buffer is used by compositor, we don't need attach it and hold one
more reference. Just check used_by_compositor, just return if it is true.
Assert error log is not need, this is normal behavior.
With latest XDG shell, we need to fait for the surface to have been
configured before we can attach a buffer to it. This is being enforce by
Weston with an error.
Fixes#933
Instead of creating a region, adding nothing to it, setting that as the
input region and destroying the region, you can instead just pass NULL
to wl_surface_set_input_region for the same effect.
Fixes#702
When waylandsink is used on some other thread than the main wayland
client thread, the waylandsink implementation is vulnerable to a
condition related to registry and surface events which handled in
seperated event queue.
The race that may happen is that after a proxy is created, but
before the queue is set, events meant to be emitted via the yet to
set queue may already have been queued on the wrong queue.
Wayland 1.11 introduced new API that allows creating a proxy
wrappper which can help to avoid this race condition.
Relaxed the wl_shell interface constrains, so application that
pass via GstContext the wl_surface can use waylandsink in a
compositor without wl_surface and zwp_fullscreen_shell.
Added support for zwp_fullscreen_shell.
https://bugzilla.gnome.org/show_bug.cgi?id=796772
We change the video info base on the received buffer. We need to
rollback these changes whenever we want to copy into our internal
pool of buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=790057
The SHM interface does not allow passing arbitrary strides and offsets,
for this reason, we simply disable this feature from the proposed pool.
This fixes video artifact seen when using the FFMPEG based video
decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=790057
