RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/video/out/vo_wlshm.c

318 lines
8.5 KiB
C
Raw Normal View History

Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
/*
* This file is part of mpv video player.
*
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
#include <errno.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <time.h>
#include <unistd.h>
#include <libswscale/swscale.h>
vo_wlshm: support big endian systems The video was otherwise blue, and that’s not how it should be. :)
2021-02-04 18:11:30 +00:00
#include "osdep/endian.h"
vo: move wayland presentation to separate files Wayland had some specific code that it used for implementing the presentation time protocol. It turns out that xorg's present extension is extremely similar, so it would be silly to duplicate this whole mess again. Factor this out to separate, independent code and introduce the mp_present struct which is used for handling the ust/msc values and some other associated values. Also, add in some helper functions so all the dirty details live specifically in present_sync. The only wayland-specific part is actually obtaining ust/msc values. Since only wayland or xorg are expected to use this, add a conditional to the build that only adds this file when either one of those are present. You may observe that sbc is completely omitted. This field existed in wayland, but was completely unused (presentation time doesn't return this). Xorg's present extension also doesn't use this so just get rid of it all together. The actual calculation is slightly altered so it is correct for our purposes. We want to get the presentation event of the last frame that was just occured (this function executes right after the buffer swap). The adjustment is to just remove the vsync_duration subtraction. Also, The overly-complicated queue approach is removed. This has no actual use in practice (on wayland or xorg). Presentation statistics are only ever used after the immediate preceding swap to update vsync timings or thrown away.
2022-06-10 16:49:28 +00:00
#include "present_sync.h"
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
#include "sub/osd.h"
#include "video/fmt-conversion.h"
#include "video/mp_image.h"
#include "video/sws_utils.h"
#include "vo.h"
#include "wayland_common.h"
struct buffer {
struct vo *vo;
size_t size;
struct wl_shm_pool *pool;
struct wl_buffer *buffer;
struct mp_image mpi;
struct buffer *next;
};
struct priv {
struct mp_sws_context *sws;
struct buffer *free_buffers;
struct mp_rect src;
struct mp_rect dst;
struct mp_osd_res osd;
};
static void buffer_handle_release(void *data, struct wl_buffer *wl_buffer)
{
struct buffer *buf = data;
struct vo *vo = buf->vo;
struct priv *p = vo->priv;
if (buf->mpi.w == vo->dwidth && buf->mpi.h == vo->dheight) {
buf->next = p->free_buffers;
p->free_buffers = buf;
} else {
talloc_free(buf);
}
}
static const struct wl_buffer_listener buffer_listener = {
buffer_handle_release,
};
static void buffer_destroy(void *p)
{
struct buffer *buf = p;
wl_buffer_destroy(buf->buffer);
wl_shm_pool_destroy(buf->pool);
munmap(buf->mpi.planes[0], buf->size);
}
static struct buffer *buffer_create(struct vo *vo, int width, int height)
{
struct priv *p = vo->priv;
struct vo_wayland_state *wl = vo->wl;
int fd;
int stride;
size_t size;
uint8_t *data;
struct buffer *buf;
stride = MP_ALIGN_UP(width * 4, 16);
size = height * stride;
vo: move allocate_memfd method to wayland_common
2022-05-30 17:19:23 +00:00
fd = vo_wayland_allocate_memfd(vo, size);
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
if (fd < 0)
goto error0;
data = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (data == MAP_FAILED)
goto error1;
buf = talloc_zero(NULL, struct buffer);
if (!buf)
goto error2;
buf->vo = vo;
buf->size = size;
mp_image_set_params(&buf->mpi, &p->sws->dst);
vo_wlshm, vo_drm: set image size with mp_image_set_size The image w and h members must match params.w and params.h, so should not be changed directly. The helper function mp_image_set_size is designed for this purpose, so just use that instead. This prevents an assertion error with the rewritten draw_bmp. Fixes #7721.
2020-05-16 22:25:58 +00:00
mp_image_set_size(&buf->mpi, width, height);
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
buf->mpi.planes[0] = data;
buf->mpi.stride[0] = stride;
buf->pool = wl_shm_create_pool(wl->shm, fd, size);
if (!buf->pool)
goto error3;
buf->buffer = wl_shm_pool_create_buffer(buf->pool, 0, width, height,
stride, WL_SHM_FORMAT_XRGB8888);
if (!buf->buffer)
goto error4;
wl_buffer_add_listener(buf->buffer, &buffer_listener, buf);
wayland: only render if we have frame callback Back in the olden days, mpv's wayland backend was driven by the frame callback. This had several issues and was removed in favor of the current approach which allowed some advanced features (like display-resample and presentation time) to actually work properly. However as a consequence, it meant that mpv always rendered, even if the surface was hidden. Wayland people consider this "wasteful" (and well they aren't wrong). This commit aims to avoid wasteful rendering by doing some additional checks in the swapchain. There's three main parts to this. 1. Wayland EGL now uses an external swapchain (like the drm context). Before we start a new frame, we check to see if we are waiting on a callback from the compositor. If there is no wait, then go ahead and proceed to render the frame, swap buffers, and then initiate vo_wayland_wait_frame to poll (with a timeout) for the next potential callback. If we are still waiting on callback from the compositor when starting a new frame, then we simple skip rendering it entirely until the surface comes back into view. 2. Wayland on vulkan has essentially the same approach although the details are a little different. The ra_vk_ctx does not have support for an external swapchain and although such a mechanism could theoretically be added, it doesn't make much sense with libplacebo. Instead, start_frame was added as a param and used to check for callback. 3. For wlshm, it's simply a matter of adding frame callback to it, leveraging vo_wayland_wait_frame, and using the frame callback value to whether or not to draw the image.
2020-09-18 17:29:53 +00:00
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
close(fd);
talloc_set_destructor(buf, buffer_destroy);
return buf;
error4:
wl_shm_pool_destroy(buf->pool);
error3:
talloc_free(buf);
error2:
munmap(data, size);
error1:
close(fd);
error0:
return NULL;
}
vo_wlshm: cleanup on failure If failure occurs during preinit, vo_wlshm should goto an error and cleaup itself like the other VOs.
2023-01-08 18:34:21 +00:00
static void uninit(struct vo *vo)
{
struct priv *p = vo->priv;
struct buffer *buf;
while (p->free_buffers) {
buf = p->free_buffers;
p->free_buffers = buf->next;
talloc_free(buf);
}
vo_wayland_uninit(vo);
}
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
static int preinit(struct vo *vo)
{
struct priv *p = vo->priv;
if (!vo_wayland_init(vo))
vo_wlshm: cleanup on failure If failure occurs during preinit, vo_wlshm should goto an error and cleaup itself like the other VOs.
2023-01-08 18:34:21 +00:00
goto err;
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 01:06:14 +00:00
if (!vo->wl->shm) {
MP_FATAL(vo->wl, "Compositor doesn't support the %s protocol!\n",
wl_shm_interface.name);
vo_wlshm: cleanup on failure If failure occurs during preinit, vo_wlshm should goto an error and cleaup itself like the other VOs.
2023-01-08 18:34:21 +00:00
goto err;
wayland: error out if essential protocol support is missing Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
2022-11-15 01:06:14 +00:00
}
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
p->sws = mp_sws_alloc(vo);
sws_utils: shuffle around some shit Purpose uncertain. I guess it's slightly better, maybe. The move of the sws/zimg options from VO opts (vo_opt_list) to the top-level option list is tricky. VO opts have some helper code in vo.c, that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's because updating certain VO options used to be this way (and not just the panscan option). This isn't needed anymore for sws/zimg options, so explicitly move them away.
2019-10-31 14:18:57 +00:00
p->sws->log = vo->log;
mp_sws_enable_cmdline_opts(p->sws, vo->global);
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
return 0;
vo_wlshm: cleanup on failure If failure occurs during preinit, vo_wlshm should goto an error and cleaup itself like the other VOs.
2023-01-08 18:34:21 +00:00
err:
uninit(vo);
return -1;
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
}
static int query_format(struct vo *vo, int format)
{
return sws_isSupportedInput(imgfmt2pixfmt(format));
}
static int reconfig(struct vo *vo, struct mp_image_params *params)
{
struct priv *p = vo->priv;
if (!vo_wayland_reconfig(vo))
return -1;
p->sws->src = *params;
return 0;
}
static int resize(struct vo *vo)
{
struct priv *p = vo->priv;
struct vo_wayland_state *wl = vo->wl;
const int32_t width = wl->scaling * mp_rect_w(wl->geometry);
const int32_t height = wl->scaling * mp_rect_h(wl->geometry);
struct buffer *buf;
wayland: update opaque region on runtime Made possible with 00b9c81. 34b8adc let the wayland surface set an opaque region depending on if alpha was set by the user or not. However, there was no attempted detection for runtime changes and it is possible (at least in wayland vulkan) to toggle the alpha on and off. So this meant, we could be incorrectly signalling an opaque region if the user happened to change the alpha. Additionally, add a helper function for this and use it everywhere we want to set the opaque region.
2020-10-05 15:28:37 +00:00
vo_wayland_set_opaque_region(wl, 0);
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
vo->want_redraw = true;
vo->dwidth = width;
vo->dheight = height;
vo_get_src_dst_rects(vo, &p->src, &p->dst, &p->osd);
p->sws->dst = (struct mp_image_params) {
vo_wlshm: support big endian systems The video was otherwise blue, and that’s not how it should be. :)
2021-02-04 18:11:30 +00:00
.imgfmt = MP_SELECT_LE_BE(IMGFMT_BGR0, IMGFMT_0RGB),
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
.w = width,
.h = height,
.p_w = 1,
.p_h = 1,
};
mp_image_params_guess_csp(&p->sws->dst);
while (p->free_buffers) {
buf = p->free_buffers;
p->free_buffers = buf->next;
talloc_free(buf);
}
Revert "wayland: conditionally commit surface on resize" 30dcfbc is a workaround for incorrect border sizes that could occur on sway/wlroots in certain edge cases. This seemed harmless enough, but it turns out that on mutter the extra wl_surface_commit somehow causes the window always go to the top left of the screen after you leave fullscreen. No idea why this occurs, but the original commit is a workaround a sway bug and causing regressions for other users isn't right despite the author being biased towards sway/wlroots. This reverts commit 30dcfbc9cb3f77dbb729fb6f95ffde7dbdddc4cb.
2020-11-08 15:51:52 +00:00
return mp_sws_reinit(p->sws);
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
}
static int control(struct vo *vo, uint32_t request, void *data)
{
vo_wlshm: properly support video panscan Turns out it was already doing this under the hood the entire time. The only catch is that the vo just needed a resize.
2023-01-10 01:27:35 +00:00
switch (request) {
case VOCTRL_SET_PANSCAN:
resize(vo);
return VO_TRUE;
}
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
int events = 0;
int ret = vo_wayland_control(vo, &events, request, data);
if (events & VO_EVENT_RESIZE)
ret = resize(vo);
wayland: only render if we have frame callback Back in the olden days, mpv's wayland backend was driven by the frame callback. This had several issues and was removed in favor of the current approach which allowed some advanced features (like display-resample and presentation time) to actually work properly. However as a consequence, it meant that mpv always rendered, even if the surface was hidden. Wayland people consider this "wasteful" (and well they aren't wrong). This commit aims to avoid wasteful rendering by doing some additional checks in the swapchain. There's three main parts to this. 1. Wayland EGL now uses an external swapchain (like the drm context). Before we start a new frame, we check to see if we are waiting on a callback from the compositor. If there is no wait, then go ahead and proceed to render the frame, swap buffers, and then initiate vo_wayland_wait_frame to poll (with a timeout) for the next potential callback. If we are still waiting on callback from the compositor when starting a new frame, then we simple skip rendering it entirely until the surface comes back into view. 2. Wayland on vulkan has essentially the same approach although the details are a little different. The ra_vk_ctx does not have support for an external swapchain and although such a mechanism could theoretically be added, it doesn't make much sense with libplacebo. Instead, start_frame was added as a param and used to check for callback. 3. For wlshm, it's simply a matter of adding frame callback to it, leveraging vo_wayland_wait_frame, and using the frame callback value to whether or not to draw the image.
2020-09-18 17:29:53 +00:00
if (events & VO_EVENT_EXPOSE)
vo->want_redraw = true;
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
vo_event(vo, events);
return ret;
}
vo_wlshm: use draw_frame instead of draw_image draw_image is an old API that was deprecated long ago. However when wlshm was originally added, it used draw_image. There's no particular reason for this and it can trivially be switched to draw_frame instead. This has some real advantages (notably --vo=wlshm --idle --force-window actually works).
2022-04-20 19:16:44 +00:00
static void draw_frame(struct vo *vo, struct vo_frame *frame)
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
{
struct priv *p = vo->priv;
struct vo_wayland_state *wl = vo->wl;
vo_wlshm: use draw_frame instead of draw_image draw_image is an old API that was deprecated long ago. However when wlshm was originally added, it used draw_image. There's no particular reason for this and it can trivially be switched to draw_frame instead. This has some real advantages (notably --vo=wlshm --idle --force-window actually works).
2022-04-20 19:16:44 +00:00
struct mp_image *src = frame->current;
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
struct buffer *buf;
wayland: shuffle around the render loop again Take two. f4e89dd went wrong by moving vo_wayland_wait_frame before start_frame was called. Whether or not this matters depends on the compositor, but some weird things can happen. Basically, it's a scheduling issue. vo_wayland_wait_frame queues all events and sends them to the server to process (with no blocking if presentation time is available). If mpv changes state while rendering (and this function is called before every frame is drawn), then that event also gets dispatched and sent to the compositor. This, in some cases, can cause some funny behavior because the next frame gets attached to the surface while the old buffer is getting released. It's safer to call this function after the swap already happens and well before mpv calls its next draw. There's no weird scheduling of events, and the compositor log is more normal. The second part of this is to fix some stuttering issues. This is mostly just conjecture, but probably what was happening was this thing called "composition". The easiest way to see this is to play a video on the default audio sync mode (probably easiest to see on a typical 23.976 video). Have that in a window and float it over firefox (floating windows are bloat on a tiling wm anyway). Then in firefox, do some short bursts of smooth scrolling (likely uses egl). Some stutter in video rendering could be observed, particularly in panning shots. Compositors are supposed to prevent tearing so what likely was happening was that the compositor was simply holding the buffer a wee bit longer to make sure it happened in sync with the smooth scrolling. Because the mpv code waits precisely on presentation time, the loop would timeout on occasion instead of receiving the frame callback. This would then lead to a skipped frame when rendering and thus causing stuttering. The fix is simple: just only count consecutive timeouts as not receiving frame callback. If a compositor holds the mpv buffer slightly longer to avoid tearing, then we will definitely receive frame callback on the next round of the render loop. This logic also appears to be sound for plasma (funfact: Plasma always returns frame callback even when the window is hidden. Not sure what's up with that, but luckily it doesn't matter to us.), so get rid of the goofy 1/vblank_time thing and just keep it a simple > 1 check.
2021-05-23 19:36:19 +00:00
wayland: unify visibility checking code A bit of a personal pet peeve. vulkan, opengl, and wlshm all had different methods for doing wayland's "check for visibility before drawing" thing. The specific backend doesn't matter in this case and the logic should all be shared. Additionally, the external swapchain that the opengl code on wayland uses is done away with and it instead copies vulkan by using a param. This keeps things looking more uniform across backends and also makes it easier to extend to other platforms (see the next couple of commits).
2022-04-07 04:01:21 +00:00
bool render = vo_wayland_check_visible(vo);
wayland: shuffle around the render loop again Take two. f4e89dd went wrong by moving vo_wayland_wait_frame before start_frame was called. Whether or not this matters depends on the compositor, but some weird things can happen. Basically, it's a scheduling issue. vo_wayland_wait_frame queues all events and sends them to the server to process (with no blocking if presentation time is available). If mpv changes state while rendering (and this function is called before every frame is drawn), then that event also gets dispatched and sent to the compositor. This, in some cases, can cause some funny behavior because the next frame gets attached to the surface while the old buffer is getting released. It's safer to call this function after the swap already happens and well before mpv calls its next draw. There's no weird scheduling of events, and the compositor log is more normal. The second part of this is to fix some stuttering issues. This is mostly just conjecture, but probably what was happening was this thing called "composition". The easiest way to see this is to play a video on the default audio sync mode (probably easiest to see on a typical 23.976 video). Have that in a window and float it over firefox (floating windows are bloat on a tiling wm anyway). Then in firefox, do some short bursts of smooth scrolling (likely uses egl). Some stutter in video rendering could be observed, particularly in panning shots. Compositors are supposed to prevent tearing so what likely was happening was that the compositor was simply holding the buffer a wee bit longer to make sure it happened in sync with the smooth scrolling. Because the mpv code waits precisely on presentation time, the loop would timeout on occasion instead of receiving the frame callback. This would then lead to a skipped frame when rendering and thus causing stuttering. The fix is simple: just only count consecutive timeouts as not receiving frame callback. If a compositor holds the mpv buffer slightly longer to avoid tearing, then we will definitely receive frame callback on the next round of the render loop. This logic also appears to be sound for plasma (funfact: Plasma always returns frame callback even when the window is hidden. Not sure what's up with that, but luckily it doesn't matter to us.), so get rid of the goofy 1/vblank_time thing and just keep it a simple > 1 check.
2021-05-23 19:36:19 +00:00
if (!render)
wayland: simplify render loop This is actually a very nice simplification that should have been thought of years ago (sue me). In a nutshell, the story with the wayland code is that the frame callback and swap buffer behavior doesn't fit very well with mpv's rendering loop. It's been refactored/changed quite a few times over the years and works well enough but things could be better. The current iteration works with an external swapchain to check if we have frame callback before deciding whether or not to render. This logic was implemented in both egl and vulkan. This does have its warts however. There's some hidden state detection logic which works but is kind of ugly. Since wayland doesn't allow clients to know if they are actually visible (questionable but whatever), you can just reasonably assume that if a bunch of callbacks are missed in a row, you're probably not visible. That's fine, but it is indeed less than ideal since the threshold is basically entirely arbitrary and mpv does do a few wasteful renders before it decides that the window is actually hidden. The biggest urk in the vo_wayland_wait_frame is the use of wl_display_roundtrip. Wayland developers would probably be offended by the way mpv abuses that function, but essentially it was a way to have semi-blocking behavior needed for display-resample to work. Since the swap interval must be 0 on wayland (otherwise it will block the entire player's rendering loop), we need some other way to wait on vsync. The idea here was to dispatch and poll a bunch of wayland events, wait (with a timeout) until we get frame callback, and then wait for the compositor to process it. That pretty much perfectly waits on vsync and lets us keep all the good timings and all that jazz that we want for mpv. The problem is that wl_display_roundtrip is conceptually a bad function. It can internally call wl_display_dispatch which in certain instances, empty event queue, will block forever. Now strictly speaking, this probably will never, ever happen (once I was able to to trigger it by hardcoding an error into a compositor), but ideally vo_wayland_wait_frame should never infinitely block and stall the player. Unfortunately, removing that function always lead to problems with timings and unsteady vsync intervals so it survived many refactors. Until now, of course. In wayland, the ideal is to never do wasteful rendering (i.e. don't render if the window isn't visible). Instead of wrestling around with hidden states and possible missed vblanks, let's rearrange the wayland rendering logic so we only ever draw a frame when the frame callback is returned to use (within a reasonable timeout to avoid blocking forever). This slight rearrangement of the wait allows for several simplifications to be made. Namely, wl_display_roundtrip stops being needed. Instead, we can rely entirely on totally nonblocking calls (dispatch_pending, flush, and so on). We still need to poll the fd here to actually get the frame callback event from the compositor, but there's no longer any reason to do extra waiting. As soon as we get the callback, we immediately draw. This works quite well and has stable vsync (display-resample and audio). Additionally, all of the logic about hidden states is no longer needed. If vo_wayland_wait_frame times out, it's okay to assume immediately that the window is not visible and skip rendering. Unfortunately, there's one limitation on this new approach. It will only work correctly if the compositor implements presentation time. That means a reduced version of the old way still has to be carried around in vo_wayland_wait_frame. So if the compositor has no presentation time, then we are forced to use wl_display_roundtrip and juggle some funny assumptions about whether or not the window is hidden or not. Plasma is the only real notable compositor without presentation time at this stage so perhaps this "legacy" mechanism could be removed in the future.
2021-05-17 19:36:59 +00:00
return;
wayland: only render if we have frame callback Back in the olden days, mpv's wayland backend was driven by the frame callback. This had several issues and was removed in favor of the current approach which allowed some advanced features (like display-resample and presentation time) to actually work properly. However as a consequence, it meant that mpv always rendered, even if the surface was hidden. Wayland people consider this "wasteful" (and well they aren't wrong). This commit aims to avoid wasteful rendering by doing some additional checks in the swapchain. There's three main parts to this. 1. Wayland EGL now uses an external swapchain (like the drm context). Before we start a new frame, we check to see if we are waiting on a callback from the compositor. If there is no wait, then go ahead and proceed to render the frame, swap buffers, and then initiate vo_wayland_wait_frame to poll (with a timeout) for the next potential callback. If we are still waiting on callback from the compositor when starting a new frame, then we simple skip rendering it entirely until the surface comes back into view. 2. Wayland on vulkan has essentially the same approach although the details are a little different. The ra_vk_ctx does not have support for an external swapchain and although such a mechanism could theoretically be added, it doesn't make much sense with libplacebo. Instead, start_frame was added as a param and used to check for callback. 3. For wlshm, it's simply a matter of adding frame callback to it, leveraging vo_wayland_wait_frame, and using the frame callback value to whether or not to draw the image.
2020-09-18 17:29:53 +00:00
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
buf = p->free_buffers;
if (buf) {
p->free_buffers = buf->next;
} else {
buf = buffer_create(vo, vo->dwidth, vo->dheight);
if (!buf) {
wl_surface_attach(wl->surface, NULL, 0, 0);
return;
}
}
if (src) {
struct mp_image dst = buf->mpi;
struct mp_rect src_rc;
struct mp_rect dst_rc;
src_rc.x0 = MP_ALIGN_DOWN(p->src.x0, MPMAX(src->fmt.align_x, 4));
src_rc.y0 = MP_ALIGN_DOWN(p->src.y0, MPMAX(src->fmt.align_y, 4));
src_rc.x1 = p->src.x1 - (p->src.x0 - src_rc.x0);
src_rc.y1 = p->src.y1 - (p->src.y0 - src_rc.y0);
dst_rc.x0 = MP_ALIGN_DOWN(p->dst.x0, MPMAX(dst.fmt.align_x, 4));
dst_rc.y0 = MP_ALIGN_DOWN(p->dst.y0, MPMAX(dst.fmt.align_y, 4));
dst_rc.x1 = p->dst.x1 - (p->dst.x0 - dst_rc.x0);
dst_rc.y1 = p->dst.y1 - (p->dst.y0 - dst_rc.y0);
mp_image_crop_rc(src, src_rc);
mp_image_crop_rc(&dst, dst_rc);
mp_sws_scale(p->sws, &dst, src);
if (dst_rc.y0 > 0)
mp_image_clear(&buf->mpi, 0, 0, buf->mpi.w, dst_rc.y0);
if (buf->mpi.h > dst_rc.y1)
mp_image_clear(&buf->mpi, 0, dst_rc.y1, buf->mpi.w, buf->mpi.h);
if (dst_rc.x0 > 0)
mp_image_clear(&buf->mpi, 0, dst_rc.y0, dst_rc.x0, dst_rc.y1);
if (buf->mpi.w > dst_rc.x1)
mp_image_clear(&buf->mpi, dst_rc.x1, dst_rc.y0, buf->mpi.w, dst_rc.y1);
osd_draw_on_image(vo->osd, p->osd, src->pts, 0, &buf->mpi);
} else {
mp_image_clear(&buf->mpi, 0, 0, buf->mpi.w, buf->mpi.h);
osd_draw_on_image(vo->osd, p->osd, 0, 0, &buf->mpi);
}
wl_surface_attach(wl->surface, buf->buffer, 0, 0);
}
static void flip_page(struct vo *vo)
{
struct vo_wayland_state *wl = vo->wl;
wayland: use wl_surface_damage_buffer Since 2018, wl_surface_damage_buffer has been explicitly preferred and recommended over wl_surface_damage*. mpv was still using the old function in a couple of spots. The only difference is that we need to pass buffer coordinates instead of surface coordinates. In vo_wlshm, this is done by using vo->dwidth/vo->dheight since that is always used whenever wl_buffers are created. In the case of the cursor surfaace, we actually already passed buffer coordinates to it (img->width/height) which was probablly technically wrong with wl_surface_damage, but it doesn't really matter in practice. This requires bumping wl_compositor to version 4 which is no problem since this dates back to 2015*. https://gitlab.freedesktop.org/wayland/wayland/-/commit/921d0548035673a1bf6aeb9396b9bc728133411e https://gitlab.freedesktop.org/wayland/wayland/-/commit/3384f69ecf043d62a4e036c0353c2daa01d7c4d0
2022-04-27 19:03:34 +00:00
wl_surface_damage_buffer(wl->surface, 0, 0, vo->dwidth,
vo->dheight);
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
wl_surface_commit(wl->surface);
wayland: only render if we have frame callback Back in the olden days, mpv's wayland backend was driven by the frame callback. This had several issues and was removed in favor of the current approach which allowed some advanced features (like display-resample and presentation time) to actually work properly. However as a consequence, it meant that mpv always rendered, even if the surface was hidden. Wayland people consider this "wasteful" (and well they aren't wrong). This commit aims to avoid wasteful rendering by doing some additional checks in the swapchain. There's three main parts to this. 1. Wayland EGL now uses an external swapchain (like the drm context). Before we start a new frame, we check to see if we are waiting on a callback from the compositor. If there is no wait, then go ahead and proceed to render the frame, swap buffers, and then initiate vo_wayland_wait_frame to poll (with a timeout) for the next potential callback. If we are still waiting on callback from the compositor when starting a new frame, then we simple skip rendering it entirely until the surface comes back into view. 2. Wayland on vulkan has essentially the same approach although the details are a little different. The ra_vk_ctx does not have support for an external swapchain and although such a mechanism could theoretically be added, it doesn't make much sense with libplacebo. Instead, start_frame was added as a param and used to check for callback. 3. For wlshm, it's simply a matter of adding frame callback to it, leveraging vo_wayland_wait_frame, and using the frame callback value to whether or not to draw the image.
2020-09-18 17:29:53 +00:00
wayland: shuffle around the render loop again Take two. f4e89dd went wrong by moving vo_wayland_wait_frame before start_frame was called. Whether or not this matters depends on the compositor, but some weird things can happen. Basically, it's a scheduling issue. vo_wayland_wait_frame queues all events and sends them to the server to process (with no blocking if presentation time is available). If mpv changes state while rendering (and this function is called before every frame is drawn), then that event also gets dispatched and sent to the compositor. This, in some cases, can cause some funny behavior because the next frame gets attached to the surface while the old buffer is getting released. It's safer to call this function after the swap already happens and well before mpv calls its next draw. There's no weird scheduling of events, and the compositor log is more normal. The second part of this is to fix some stuttering issues. This is mostly just conjecture, but probably what was happening was this thing called "composition". The easiest way to see this is to play a video on the default audio sync mode (probably easiest to see on a typical 23.976 video). Have that in a window and float it over firefox (floating windows are bloat on a tiling wm anyway). Then in firefox, do some short bursts of smooth scrolling (likely uses egl). Some stutter in video rendering could be observed, particularly in panning shots. Compositors are supposed to prevent tearing so what likely was happening was that the compositor was simply holding the buffer a wee bit longer to make sure it happened in sync with the smooth scrolling. Because the mpv code waits precisely on presentation time, the loop would timeout on occasion instead of receiving the frame callback. This would then lead to a skipped frame when rendering and thus causing stuttering. The fix is simple: just only count consecutive timeouts as not receiving frame callback. If a compositor holds the mpv buffer slightly longer to avoid tearing, then we will definitely receive frame callback on the next round of the render loop. This logic also appears to be sound for plasma (funfact: Plasma always returns frame callback even when the window is hidden. Not sure what's up with that, but luckily it doesn't matter to us.), so get rid of the goofy 1/vblank_time thing and just keep it a simple > 1 check.
2021-05-23 19:36:19 +00:00
if (!wl->opts->disable_vsync)
vo_wayland_wait_frame(wl);
wayland: correctly handle non-CLOCK_MONOTONIC clocks The wayland presentation time code currently always assumes that only CLOCK_MONOTONIC can be used. There is a naive attempt to ignore clocks other than CLOCK_MONOTONIC, but the logic is actually totally wrong and the timestamps would be used anyway. Fix this by checking a use_present bool (similar to use_present in xorg) which is set to true if we receive a valid clock in the clockid event. Additionally, allow CLOCK_MONOTONIC_RAW as a valid clockid. In practice, it should be the same as CLOCK_MONOTONIC for us (ntp/adjustime difference wouldn't matter). Since this is a linux-specific clock, add a define for it if it is not found.
2022-10-04 16:05:00 +00:00
if (wl->use_present)
vo: move wayland presentation to separate files Wayland had some specific code that it used for implementing the presentation time protocol. It turns out that xorg's present extension is extremely similar, so it would be silly to duplicate this whole mess again. Factor this out to separate, independent code and introduce the mp_present struct which is used for handling the ust/msc values and some other associated values. Also, add in some helper functions so all the dirty details live specifically in present_sync. The only wayland-specific part is actually obtaining ust/msc values. Since only wayland or xorg are expected to use this, add a conditional to the build that only adds this file when either one of those are present. You may observe that sbc is completely omitted. This field existed in wayland, but was completely unused (presentation time doesn't return this). Xorg's present extension also doesn't use this so just get rid of it all together. The actual calculation is slightly altered so it is correct for our purposes. We want to get the presentation event of the last frame that was just occured (this function executes right after the buffer swap). The adjustment is to just remove the vsync_duration subtraction. Also, The overly-complicated queue approach is removed. This has no actual use in practice (on wayland or xorg). Presentation statistics are only ever used after the immediate preceding swap to update vsync timings or thrown away.
2022-06-10 16:49:28 +00:00
present_sync_swap(wl->present);
vo_wlshm: support presentation time We get presentation feedback for free thanks to the last commit. Implementing it in wlshm is pretty straightfoward from there.
2020-12-11 19:46:14 +00:00
}
static void get_vsync(struct vo *vo, struct vo_vsync_info *info)
{
struct vo_wayland_state *wl = vo->wl;
wayland: correctly handle non-CLOCK_MONOTONIC clocks The wayland presentation time code currently always assumes that only CLOCK_MONOTONIC can be used. There is a naive attempt to ignore clocks other than CLOCK_MONOTONIC, but the logic is actually totally wrong and the timestamps would be used anyway. Fix this by checking a use_present bool (similar to use_present in xorg) which is set to true if we receive a valid clock in the clockid event. Additionally, allow CLOCK_MONOTONIC_RAW as a valid clockid. In practice, it should be the same as CLOCK_MONOTONIC for us (ntp/adjustime difference wouldn't matter). Since this is a linux-specific clock, add a define for it if it is not found.
2022-10-04 16:05:00 +00:00
if (wl->use_present)
vo: move wayland presentation to separate files Wayland had some specific code that it used for implementing the presentation time protocol. It turns out that xorg's present extension is extremely similar, so it would be silly to duplicate this whole mess again. Factor this out to separate, independent code and introduce the mp_present struct which is used for handling the ust/msc values and some other associated values. Also, add in some helper functions so all the dirty details live specifically in present_sync. The only wayland-specific part is actually obtaining ust/msc values. Since only wayland or xorg are expected to use this, add a conditional to the build that only adds this file when either one of those are present. You may observe that sbc is completely omitted. This field existed in wayland, but was completely unused (presentation time doesn't return this). Xorg's present extension also doesn't use this so just get rid of it all together. The actual calculation is slightly altered so it is correct for our purposes. We want to get the presentation event of the last frame that was just occured (this function executes right after the buffer swap). The adjustment is to just remove the vsync_duration subtraction. Also, The overly-complicated queue approach is removed. This has no actual use in practice (on wayland or xorg). Presentation statistics are only ever used after the immediate preceding swap to update vsync timings or thrown away.
2022-06-10 16:49:28 +00:00
present_sync_get_info(wl->present, info);
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
}
const struct vo_driver video_out_wlshm = {
vo_drm, wo_wlshm: mention that it's software scaling (But does anyone even read --vo=help output?)
2020-02-11 20:45:16 +00:00
.description = "Wayland SHM video output (software scaling)",
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
.name = "wlshm",
.preinit = preinit,
.query_format = query_format,
.reconfig = reconfig,
.control = control,
vo_wlshm: use draw_frame instead of draw_image draw_image is an old API that was deprecated long ago. However when wlshm was originally added, it used draw_image. There's no particular reason for this and it can trivially be switched to draw_frame instead. This has some real advantages (notably --vo=wlshm --idle --force-window actually works).
2022-04-20 19:16:44 +00:00
.draw_frame = draw_frame,
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
.flip_page = flip_page,
vo_wlshm: support presentation time We get presentation feedback for free thanks to the last commit. Implementing it in wlshm is pretty straightfoward from there.
2020-12-11 19:46:14 +00:00
.get_vsync = get_vsync,
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
.wakeup = vo_wayland_wakeup,
.wait_events = vo_wayland_wait_events,
.uninit = uninit,
.priv_size = sizeof(struct priv),
};