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
When the sink receives a buffer that is neither a wl_shm one nor a
dmabuf one, this buffer is copied to an internal wl_shm buffer before
being sent to the display.
In that case, the actual size of the received buffer (which may differ
from the one negotiated in the caps) must be used.
https://bugzilla.gnome.org/show_bug.cgi?id=777841
Unless the video format has an alpha component (ARGB, ...), set the
video_surface opaque.
In the usual case where the black area_surface has the same size as the
video_surface (eg: run gst-play-1.0 video.mp4), this makes the black
surface totally occluded which makes weston compositor's life easier
since it can ignore that surface.
Also unconditionally set the black area_surface opaque.
https://bugzilla.gnome.org/show_bug.cgi?id=778078
Reset redraw_pending at display disconnection, so we can re-connect
later from a clean state (avoid endless buffer drops).
Add a log to inform of dropped buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=775791
wldisplay.c:179:15: error: comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare]
if (shm_fmt < 0)
~~~~~~~ ^ ~
gstsegmentation.cpp:419:40: error: implicit conversion from 'int' to 'char' changes value from 255 to -1 [-Werror,-Wconstant-conversion]
filter->cvFG->imageData[j] = 255;
~ ^~~
https://bugzilla.gnome.org/show_bug.cgi?id=775112
Support the wayland zwp_linux_dmabuf_unstable_v1 protocol.
SHM formats and DMABuf formats are exposed differently in caps: the
DMABuf formats are flagged with GST_CAPS_FEATURE_MEMORY_DMABUF.
No buffer pool is proposed for DMABuf buffers, it is the upstream
element responsibility to provide with such buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=711155
This is specific to when the waylandsink is not being embedded. In
this patch we pass the render lock to the window so it can safely
call gst_wl_window_set_render_rectangle() with the new size.
https://bugzilla.gnome.org/show_bug.cgi?id=722343
We already take the render lock from the wlqueue thread in some other
place which indicates that there is no use of this atomic instead of
a proper locking mechanism.
When we don't have a viewporter (scaling support), we can't use the
1x1 scaleup image trick. Instead, we need to allocate a buffer with
the same size as the area that need to have black background.
