mirror/mpv
0
0
Fork 0
mirror of https://github.com/mpv-player/mpv.git synced 2024-09-20 20:03:10 +02:00
Code
8006ff6cf6
mpv/video/out/wayland_common.c

2478 lines
80 KiB
C
Raw Normal View History

wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
/*
wayland: update license headers
2013-09-09 18:37:33 +02:00
* This file is part of mpv video player.
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 18:36:06 +01:00
* 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.
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
*
wayland: update license headers
2013-09-09 18:37:33 +02:00
* mpv is distributed in the hope that it will be useful,
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 18:36:06 +01:00
* GNU Lesser General Public License for more details.
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 18:36:06 +01:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
*/
wayland: read xcursor size from XCURSOR_SIZE env This allows compositors to set the cursor size from user configuration.
2018-10-10 19:59:04 +02:00
#include <errno.h>
#include <limits.h>
wayland: use more specific input codes header Wayland’s wl_pointer interface describes the button event’s argument as being taken from linux/input-event-codes.h, so there is no need to include the more generic linux/input.h.
2020-10-25 13:53:34 +01:00
#include <linux/input-event-codes.h>
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
#include <poll.h>
wayland: add presentation time Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
2019-10-10 21:14:40 +02:00
#include <time.h>
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
#include <unistd.h>
#include <wayland-cursor.h>
#include <xkbcommon/xkbcommon.h>
Split mpvcore/ into common/, misc/, bstr/
2013-12-17 02:39:45 +01:00
#include "common/msg.h"
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
#include "input/input.h"
#include "input/keycodes.h"
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
#include "options/m_config.h"
wayland: port to the new wakeup/wait_events framework This fits natively into the vo/backend and allows to simplify the polling code. One new change is the fact that surface_handle_enter flags VO_EVENT_WIN_STATE and VO_EVENT_RESIZE instead of only VO_EVENT_WIN_STATE. Before this, the code hackily relied on the timeout and the loop in the wait_frame function to track and set the scaling factor. Instead, this triggers mpv to run a schedule_resize and adjust the new VO output dimensions immediately. This is also more accurate since surface_handle_enter() gets called when a surface is created, moved and resized, which is exactly what the rest of the player might be interested in.
2016-07-21 13:25:30 +02:00
#include "osdep/io.h"
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
#include "osdep/timer.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 18:49:28 +02:00
#include "present_sync.h"
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
#include "wayland_common.h"
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
#include "win_state.h"
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
// Generated from wayland-protocols
#include "generated/wayland/idle-inhibit-unstable-v1.h"
vo_vaapi_wayland/wayland_common: code style fixes A bad person (AKA me) merged this stuff without paying close enough attention to the code style. Reformat this to be in-line with the rest of the wayland code and general mpv style (braces for functions on the next line, horizontally aligning arguments, some cosmetic cleanups for wayland_common.h, etc.).
2022-05-30 19:58:57 +02:00
#include "generated/wayland/linux-dmabuf-unstable-v1.h"
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
#include "generated/wayland/presentation-time.h"
#include "generated/wayland/xdg-decoration-unstable-v1.h"
build: change filenames of generated files Force them into a more consistent naming schema.
2019-06-22 00:03:31 +02:00
#include "generated/wayland/xdg-shell.h"
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
#include "generated/wayland/viewporter.h"
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_27
#include "generated/wayland/content-type-v1.h"
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
#include "generated/wayland/single-pixel-buffer-v1.h"
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
#endif
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_31
#include "generated/wayland/fractional-scale-v1.h"
#endif
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
#if WAYLAND_VERSION_MAJOR > 1 || WAYLAND_VERSION_MINOR >= 20
#define HAVE_WAYLAND_1_20
#endif
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 18:05:00 +02:00
#ifndef CLOCK_MONOTONIC_RAW
#define CLOCK_MONOTONIC_RAW 4
#endif
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const struct mp_keymap keymap[] = {
/* Special keys */
{XKB_KEY_Pause, MP_KEY_PAUSE}, {XKB_KEY_Escape, MP_KEY_ESC},
{XKB_KEY_BackSpace, MP_KEY_BS}, {XKB_KEY_Tab, MP_KEY_TAB},
{XKB_KEY_Return, MP_KEY_ENTER}, {XKB_KEY_Menu, MP_KEY_MENU},
{XKB_KEY_Print, MP_KEY_PRINT},
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
/* Cursor keys */
{XKB_KEY_Left, MP_KEY_LEFT}, {XKB_KEY_Right, MP_KEY_RIGHT},
{XKB_KEY_Up, MP_KEY_UP}, {XKB_KEY_Down, MP_KEY_DOWN},
wayland: use xdg-decoration if available
2018-11-07 13:53:46 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
/* Navigation keys */
{XKB_KEY_Insert, MP_KEY_INSERT}, {XKB_KEY_Delete, MP_KEY_DELETE},
{XKB_KEY_Home, MP_KEY_HOME}, {XKB_KEY_End, MP_KEY_END},
{XKB_KEY_Page_Up, MP_KEY_PAGE_UP}, {XKB_KEY_Page_Down, MP_KEY_PAGE_DOWN},
/* F-keys */
{XKB_KEY_F1, MP_KEY_F + 1}, {XKB_KEY_F2, MP_KEY_F + 2},
{XKB_KEY_F3, MP_KEY_F + 3}, {XKB_KEY_F4, MP_KEY_F + 4},
{XKB_KEY_F5, MP_KEY_F + 5}, {XKB_KEY_F6, MP_KEY_F + 6},
{XKB_KEY_F7, MP_KEY_F + 7}, {XKB_KEY_F8, MP_KEY_F + 8},
{XKB_KEY_F9, MP_KEY_F + 9}, {XKB_KEY_F10, MP_KEY_F +10},
{XKB_KEY_F11, MP_KEY_F +11}, {XKB_KEY_F12, MP_KEY_F +12},
wayland: add support for F13-F24 keys
2022-09-02 12:53:18 +02:00
{XKB_KEY_F13, MP_KEY_F +13}, {XKB_KEY_F14, MP_KEY_F +14},
{XKB_KEY_F15, MP_KEY_F +15}, {XKB_KEY_F16, MP_KEY_F +16},
{XKB_KEY_F17, MP_KEY_F +17}, {XKB_KEY_F18, MP_KEY_F +18},
{XKB_KEY_F19, MP_KEY_F +19}, {XKB_KEY_F20, MP_KEY_F +20},
{XKB_KEY_F21, MP_KEY_F +21}, {XKB_KEY_F22, MP_KEY_F +22},
{XKB_KEY_F23, MP_KEY_F +23}, {XKB_KEY_F24, MP_KEY_F +24},
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
/* Numpad independent of numlock */
{XKB_KEY_KP_Subtract, '-'}, {XKB_KEY_KP_Add, '+'},
{XKB_KEY_KP_Multiply, '*'}, {XKB_KEY_KP_Divide, '/'},
{XKB_KEY_KP_Enter, MP_KEY_KPENTER},
/* Numpad with numlock */
{XKB_KEY_KP_0, MP_KEY_KP0}, {XKB_KEY_KP_1, MP_KEY_KP1},
{XKB_KEY_KP_2, MP_KEY_KP2}, {XKB_KEY_KP_3, MP_KEY_KP3},
{XKB_KEY_KP_4, MP_KEY_KP4}, {XKB_KEY_KP_5, MP_KEY_KP5},
{XKB_KEY_KP_6, MP_KEY_KP6}, {XKB_KEY_KP_7, MP_KEY_KP7},
{XKB_KEY_KP_8, MP_KEY_KP8}, {XKB_KEY_KP_9, MP_KEY_KP9},
{XKB_KEY_KP_Decimal, MP_KEY_KPDEC}, {XKB_KEY_KP_Separator, MP_KEY_KPDEC},
/* Numpad without numlock */
{XKB_KEY_KP_Insert, MP_KEY_KPINS}, {XKB_KEY_KP_End, MP_KEY_KP1},
{XKB_KEY_KP_Down, MP_KEY_KP2}, {XKB_KEY_KP_Page_Down, MP_KEY_KP3},
{XKB_KEY_KP_Left, MP_KEY_KP4}, {XKB_KEY_KP_Begin, MP_KEY_KP5},
{XKB_KEY_KP_Right, MP_KEY_KP6}, {XKB_KEY_KP_Home, MP_KEY_KP7},
{XKB_KEY_KP_Up, MP_KEY_KP8}, {XKB_KEY_KP_Page_Up, MP_KEY_KP9},
{XKB_KEY_KP_Delete, MP_KEY_KPDEL},
/* Multimedia keys */
{XKB_KEY_XF86MenuKB, MP_KEY_MENU},
{XKB_KEY_XF86AudioPlay, MP_KEY_PLAY}, {XKB_KEY_XF86AudioPause, MP_KEY_PAUSE},
{XKB_KEY_XF86AudioStop, MP_KEY_STOP},
{XKB_KEY_XF86AudioPrev, MP_KEY_PREV}, {XKB_KEY_XF86AudioNext, MP_KEY_NEXT},
{XKB_KEY_XF86AudioRewind, MP_KEY_REWIND},
{XKB_KEY_XF86AudioForward, MP_KEY_FORWARD},
{XKB_KEY_XF86AudioMute, MP_KEY_MUTE},
{XKB_KEY_XF86AudioLowerVolume, MP_KEY_VOLUME_DOWN},
{XKB_KEY_XF86AudioRaiseVolume, MP_KEY_VOLUME_UP},
{XKB_KEY_XF86HomePage, MP_KEY_HOMEPAGE}, {XKB_KEY_XF86WWW, MP_KEY_WWW},
{XKB_KEY_XF86Mail, MP_KEY_MAIL}, {XKB_KEY_XF86Favorites, MP_KEY_FAVORITES},
{XKB_KEY_XF86Search, MP_KEY_SEARCH}, {XKB_KEY_XF86Sleep, MP_KEY_SLEEP},
{0, 0}
};
wayland: add presentation time Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
2019-10-10 21:14:40 +02:00
wayland: add various render-related options The newest wayland changes have some new logic that make sense to expose to users as configurable options.
2019-10-14 19:16:42 +02:00
#define OPT_BASE_STRUCT struct wayland_opts
const struct m_sub_options wayland_conf = {
.opts = (const struct m_option[]) {
wayland: add auto choice to wayland-configure-bounds Previously, this defaulted to yes and configure-bounds from the compositor would always apply. In the case where the user explicitly set autofit or geometry, this could be confusing because configure-bounds would take precedence over it. Instead, let's add an auto choice and make that the default. If we detect that the option is on auto and that there is autofit/geometry being set, then ignore the event. This should be more intuitive since someone who bothers to explicitly set mpv's geometry would naturally expect that geometry to actually apply.
2023-01-26 21:21:58 +01:00
{"wayland-configure-bounds", OPT_CHOICE(configure_bounds,
{"auto", -1}, {"no", 0}, {"yes", 1})},
options: transition options from OPT_FLAG to OPT_BOOL c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
2023-02-20 04:32:50 +01:00
{"wayland-disable-vsync", OPT_BOOL(disable_vsync)},
options: change option macros and all option declarations Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
2020-03-14 21:28:01 +01:00
{"wayland-edge-pixels-pointer", OPT_INT(edge_pixels_pointer),
M_RANGE(0, INT_MAX)},
{"wayland-edge-pixels-touch", OPT_INT(edge_pixels_touch),
M_RANGE(0, INT_MAX)},
wayland: add various render-related options The newest wayland changes have some new logic that make sense to expose to users as configurable options.
2019-10-14 19:16:42 +02:00
{0},
},
.size = sizeof(struct wayland_opts),
.defaults = &(struct wayland_opts) {
wayland: add auto choice to wayland-configure-bounds Previously, this defaulted to yes and configure-bounds from the compositor would always apply. In the case where the user explicitly set autofit or geometry, this could be confusing because configure-bounds would take precedence over it. Instead, let's add an auto choice and make that the default. If we detect that the option is on auto and that there is autofit/geometry being set, then ignore the event. This should be more intuitive since someone who bothers to explicitly set mpv's geometry would naturally expect that geometry to actually apply.
2023-01-26 21:21:58 +01:00
.configure_bounds = -1,
wayland: make the edge grab zone width user configurable Rather than hard-coding the edge grab zone width, we can make it user configurable. It seems worthwhile to have separate configs for pointer and touch usage as the defaults should be different, and a user might have both input methods in use.
2019-11-27 00:36:35 +01:00
.edge_pixels_pointer = 10,
wayland: improve behavior with touch events There's currently some touch related code in mpv wayland, but clearly nobody actually uses because it's a broken mess. Initially an attempt to distinguish between two finger touches and one finger touch was made, but there's not a good way to make this work. For whatever reason, initiating either xdg_toplevel_resize or xdg_toplevel_move blocks any other touch events from occurring (at least in plasma). Trying to call these functions anywhere else is not really useful since the serial will be invalid outside of the touch down events (well it would work in the touch up event but that's just silly). Anyways, let's just make this work sanely. Eliminate the touch entries variable completely because it's pointless. Only one finger event is ever considered at a time. Touches besides the initial one are all ignored. If a user touches and drags within the touch edge radius, then a resize event occurs. If the user touches and drags elsewhere on the window, a move event occurs. A single tap displays the osc (which is clickable if you tap again). A double tap toggles fullscreen. Additionally, the default touch edge radius of 64 pixels is way too big (at least I think so). Cut this in half to 32 which feels a lot better (on a pinephone using plasma mobile anyway).
2021-08-08 05:05:05 +02:00
.edge_pixels_touch = 32,
wayland: add various render-related options The newest wayland changes have some new logic that make sense to expose to users as configurable options.
2019-10-14 19:16:42 +02:00
},
};
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
struct vo_wayland_feedback_pool {
struct wp_presentation_feedback **fback;
struct vo_wayland_state *wl;
int len;
};
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_wayland_output {
struct vo_wayland_state *wl;
struct wl_output *output;
struct mp_rect geometry;
bool has_surface;
uint32_t id;
uint32_t flags;
int phys_width;
int phys_height;
int scale;
double refresh_rate;
char *make;
char *model;
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
char *name;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct wl_list link;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
};
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static int check_for_resize(struct vo_wayland_state *wl, wl_fixed_t x_w, wl_fixed_t y_w,
int edge_pixels, enum xdg_toplevel_resize_edge *edge);
static int get_mods(struct vo_wayland_state *wl);
static int lookupkey(int key);
static int set_cursor_visibility(struct vo_wayland_state *wl, bool on);
static int spawn_cursor(struct vo_wayland_state *wl);
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
static void add_feedback(struct vo_wayland_feedback_pool *fback_pool,
struct wp_presentation_feedback *fback);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void greatest_common_divisor(struct vo_wayland_state *wl, int a, int b);
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
static void remove_feedback(struct vo_wayland_feedback_pool *fback_pool,
struct wp_presentation_feedback *fback);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void remove_output(struct vo_wayland_output *out);
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
static void request_decoration_mode(struct vo_wayland_state *wl, uint32_t mode);
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
static void rescale_geometry(struct vo_wayland_state *wl, double old_scale);
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
static void set_geometry(struct vo_wayland_state *wl, bool resize);
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
static void set_surface_scaling(struct vo_wayland_state *wl);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void window_move(struct vo_wayland_state *wl, uint32_t serial);
/* Wayland listener boilerplate */
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void pointer_handle_enter(void *data, struct wl_pointer *pointer,
uint32_t serial, struct wl_surface *surface,
wl_fixed_t sx, wl_fixed_t sy)
{
struct vo_wayland_state *wl = data;
wl->pointer = pointer;
wl->pointer_id = serial;
wayland: reconfigure cursor on pointer enter event On wayland the cursor has to be configured each time the pointer enters. Currently if the window (re)gains the focus, the pointer is not hidden, even when configured. After the mouse has been moved the pointer hides correctly. https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_pointer: wl_pointer::enter - enter event ... When a seat's focus enters a surface, the pointer image is undefined and a client should respond to this event by setting an appropriate pointer image with the set_cursor request. Fixes #6185. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
2019-02-04 11:27:49 +01:00
set_cursor_visibility(wl, wl->cursor_visible);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
mp_input_put_key(wl->vo->input_ctx, MP_KEY_MOUSE_ENTER);
}
static void pointer_handle_leave(void *data, struct wl_pointer *pointer,
uint32_t serial, struct wl_surface *surface)
{
struct vo_wayland_state *wl = data;
mp_input_put_key(wl->vo->input_ctx, MP_KEY_MOUSE_LEAVE);
}
static void pointer_handle_motion(void *data, struct wl_pointer *pointer,
uint32_t time, wl_fixed_t sx, wl_fixed_t sy)
{
struct vo_wayland_state *wl = data;
wl->mouse_x = wl_fixed_to_int(sx) * wl->scaling;
wl->mouse_y = wl_fixed_to_int(sy) * wl->scaling;
wayland: add grab zone for resizing window with mouse Today, we support resizing wayland windows when we detect a touch event in a defined grab zone. As part of implementing pseudo-decorations, we should have equivalent functionality for mouse input. And if we detect support for actual decorations we will not activate the grab zone as the decorations will provide this.
2019-11-26 00:52:53 +01:00
wl->mouse_unscaled_x = sx;
wl->mouse_unscaled_y = sy;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
if (!wl->toplevel_configured)
wayland: don't set mouse pos on state change Sway 1.5 started sending more pointer motion events to mpv which broke the autohiding behavior. The cursor would appear again if you fullscreened. Sway had a good reason to do this because certain applications had inconsistencies between hardware cursor and software cursor without rebasing on state changes[1]. So mpv needs to take this special case into consideration. Initially, simply checking mouse coordinates for changes was considered, but this doesn't work. All coordinates are surface-local in wayland so something can appear to move in the local coordinate space but not globally. You're not allowed to know global mouse coordinates in wayland, and we don't care about local coordinate changes in mpv so this approach isn't viable. Instead, let's just keep track of a local state change. If the toplevel surface changes in some way (fullscreen, maximized, etc.), then just set a bool that lets us ignore the mp_input_set_mouse_pos function. This keeps the cursor from appearing simply because the state was changed (i.e. fullscreening). For compositors that don't send pointer motion events on a state change, this does technically mean that the initial mp_input_set_mouse_pos is never set. In practice, this isn't a noticeable difference though because moving a mouse generates a ton of motion events so you'll immediately see it on the second motion event. [1] https://github.com/swaywm/sway/issues/5594
2020-08-02 23:45:06 +02:00
mp_input_set_mouse_pos(wl->vo->input_ctx, wl->mouse_x, wl->mouse_y);
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
wl->toplevel_configured = false;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
static void pointer_handle_button(void *data, struct wl_pointer *wl_pointer,
uint32_t serial, uint32_t time, uint32_t button,
uint32_t state)
{
struct vo_wayland_state *wl = data;
wayland: check for modifier keys on pointer events The pointer button event had no code to handle any modifier keys. So this meant input combinations like Shift+MTBN_LEFT did not work. Fix this by ripping out the modifier-checking code in keyboard key event to a separate function and using it for both the keyboard and mouse events. In the case of the mouse, it is possible that the keyboard may not exist so be sure to check before trying to get any modifiers. Fixes #8239.
2020-11-07 20:47:26 +01:00
int mpmod = 0;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
state = state == WL_POINTER_BUTTON_STATE_PRESSED ? MP_KEY_STATE_DOWN
: MP_KEY_STATE_UP;
wayland: support extra mouse buttons Mouse button event codes above `BTN_EXTRA` (the ones currently defined in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`) are mapped to `MP_MBTN9` and up. (Reminder that due to historical reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely misleading; the real forward and back buttons are `BTN_SIDE` and `BTN_EXTRA` and are already mapped correctly by mpv.) This functionality is analogous to what the X11 backend supports in `video/out/x11_common.c` and what the Cocoa backend supports in `video/out/cocoa/events_view.m`.
2022-01-28 00:21:27 +01:00
if (button >= BTN_MOUSE && button < BTN_JOYSTICK) {
switch (button) {
case BTN_LEFT:
button = MP_MBTN_LEFT;
break;
case BTN_MIDDLE:
button = MP_MBTN_MID;
break;
case BTN_RIGHT:
button = MP_MBTN_RIGHT;
break;
case BTN_SIDE:
button = MP_MBTN_BACK;
break;
case BTN_EXTRA:
button = MP_MBTN_FORWARD;
break;
default:
button += MP_MBTN9 - BTN_FORWARD;
break;
}
} else {
wayland: add mouse buttons and fix axis scaling Previously, the only mouse buttons supported in wayland were left, right, and middle click. This adds the thumb back/forward buttons as valid bindings. Also it removes the old, default behavior of always sending a right click if an unrecognized mouse button is clicked. In a related but different fix, the magnitude of an axis event in wayland is not important to mpv since it internally handles all scaling. The only thing we care about is getting the sign when the event occurs.
2019-07-11 16:02:33 +02:00
button = 0;
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wayland: check for modifier keys on pointer events The pointer button event had no code to handle any modifier keys. So this meant input combinations like Shift+MTBN_LEFT did not work. Fix this by ripping out the modifier-checking code in keyboard key event to a separate function and using it for both the keyboard and mouse events. In the case of the mouse, it is possible that the keyboard may not exist so be sure to check before trying to get any modifiers. Fixes #8239.
2020-11-07 20:47:26 +01:00
if (wl->keyboard)
mpmod = get_mods(wl);
if (button)
mp_input_put_key(wl->vo->input_ctx, button | state | mpmod);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if (!mp_input_test_dragging(wl->vo->input_ctx, wl->mouse_x, wl->mouse_y) &&
wayland: no mouse dragging in fullscreen/maximized The wayland code takes mouse dragging into account in order to trigger a client-side request for a window move or window resize. According to the xdg-shell spec*, "[t]he server may ignore move[/resize] requests depending on the state of the surface (e.g. fullscreen or maximized)". Since it is not actually a hard requirement, that means the compositor could actually respond to a clientside move/resize request even if the mpv window was fullscreen. For example, it was pointed out that in sway, if mpv is a floating window, you could drag it around off screen even though the window is fullscreen. This kind of behavior does not really have any practical use. A user can should pan a video if he/she wishes to move its orientation while fullscreen (or maximized for that manner). Naturally, a maximized or fullscreened window should never be manually resized (every compositor likely ignores this anyway). The fix is to simply just not trigger the smecial mouse dragging case if the wayland surface is fullscreened or maximized. *:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/stable/xdg-shell/xdg-shell.xml
2021-03-02 23:38:54 +01:00
(!wl->vo_opts->fullscreen) && (!wl->vo_opts->window_maximized) &&
wayland: add grab zone for resizing window with mouse Today, we support resizing wayland windows when we detect a touch event in a defined grab zone. As part of implementing pseudo-decorations, we should have equivalent functionality for mouse input. And if we detect support for actual decorations we will not activate the grab zone as the decorations will provide this.
2019-11-26 00:52:53 +01:00
(button == MP_MBTN_LEFT) && (state == MP_KEY_STATE_DOWN)) {
uint32_t edges;
// Implement an edge resize zone if there are no decorations
if (!wl->xdg_toplevel_decoration &&
check_for_resize(wl, wl->mouse_unscaled_x, wl->mouse_unscaled_y,
wayland: make the edge grab zone width user configurable Rather than hard-coding the edge grab zone width, we can make it user configurable. It seems worthwhile to have separate configs for pointer and touch usage as the defaults should be different, and a user might have both input methods in use.
2019-11-27 00:36:35 +01:00
wl->opts->edge_pixels_pointer, &edges))
wayland: add grab zone for resizing window with mouse Today, we support resizing wayland windows when we detect a touch event in a defined grab zone. As part of implementing pseudo-decorations, we should have equivalent functionality for mouse input. And if we detect support for actual decorations we will not activate the grab zone as the decorations will provide this.
2019-11-26 00:52:53 +01:00
xdg_toplevel_resize(wl->xdg_toplevel, wl->seat, serial, edges);
else
window_move(wl, serial);
wayland: explictly send an UP event for left click In the wayland code, the left mouse click is treated a bit differently. Dragging the left click allows mpv to request a window move to the compositor. In some cases, this can also request a window resize if the osc-windowcontrols are enabled. These functions had the strange side effect of messing up mpv's deadzone (it seemed to disappear completely). A harmless enough workaround is to just explictly send an UP event for left click after the move/resize functions are finished executing. The xdg_toplevel move and resize functions both finish after the button press is let go, so we are guarenteed to have the left click in the UP state here. Sending this event probably unconfuses some calculation somewhere thus fixing the deadzone bug. It feels a little silly, but it's safe and works. Fixes #7651.
2020-04-23 21:49:18 +02:00
// Explictly send an UP event after the client finishes a move/resize
mp_input_put_key(wl->vo->input_ctx, button | MP_KEY_STATE_UP);
wayland: add grab zone for resizing window with mouse Today, we support resizing wayland windows when we detect a touch event in a defined grab zone. As part of implementing pseudo-decorations, we should have equivalent functionality for mouse input. And if we detect support for actual decorations we will not activate the grab zone as the decorations will provide this.
2019-11-26 00:52:53 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
static void pointer_handle_axis(void *data, struct wl_pointer *wl_pointer,
uint32_t time, uint32_t axis, wl_fixed_t value)
{
struct vo_wayland_state *wl = data;
wayland: simplify mouse wheel direction calculation Based on an idea by sfan5. Remove abs usage, and instead just check for negative value, and set variable to either +/-1.
2020-03-18 19:14:50 +01:00
wayland: support modifiers during axis events It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
2021-11-20 16:13:06 +01:00
int mpmod = get_mods(wl);
wayland: simplify mouse wheel direction calculation Based on an idea by sfan5. Remove abs usage, and instead just check for negative value, and set variable to either +/-1.
2020-03-18 19:14:50 +01:00
double val = wl_fixed_to_double(value) < 0 ? -1 : 1;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
switch (axis) {
case WL_POINTER_AXIS_VERTICAL_SCROLL:
if (value > 0)
wayland: support modifiers during axis events It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
2021-11-20 16:13:06 +01:00
mp_input_put_wheel(wl->vo->input_ctx, MP_WHEEL_DOWN | mpmod, +val);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if (value < 0)
wayland: support modifiers during axis events It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
2021-11-20 16:13:06 +01:00
mp_input_put_wheel(wl->vo->input_ctx, MP_WHEEL_UP | mpmod, -val);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
break;
case WL_POINTER_AXIS_HORIZONTAL_SCROLL:
if (value > 0)
wayland: support modifiers during axis events It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
2021-11-20 16:13:06 +01:00
mp_input_put_wheel(wl->vo->input_ctx, MP_WHEEL_RIGHT | mpmod, +val);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if (value < 0)
wayland: support modifiers during axis events It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
2021-11-20 16:13:06 +01:00
mp_input_put_wheel(wl->vo->input_ctx, MP_WHEEL_LEFT | mpmod, -val);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
break;
}
}
static const struct wl_pointer_listener pointer_listener = {
pointer_handle_enter,
pointer_handle_leave,
pointer_handle_motion,
pointer_handle_button,
pointer_handle_axis,
};
static void touch_handle_down(void *data, struct wl_touch *wl_touch,
uint32_t serial, uint32_t time, struct wl_surface *surface,
int32_t id, wl_fixed_t x_w, wl_fixed_t y_w)
{
struct vo_wayland_state *wl = data;
wl->mouse_x = wl_fixed_to_int(x_w) * wl->scaling;
wl->mouse_y = wl_fixed_to_int(y_w) * wl->scaling;
wayland: improve behavior with touch events There's currently some touch related code in mpv wayland, but clearly nobody actually uses because it's a broken mess. Initially an attempt to distinguish between two finger touches and one finger touch was made, but there's not a good way to make this work. For whatever reason, initiating either xdg_toplevel_resize or xdg_toplevel_move blocks any other touch events from occurring (at least in plasma). Trying to call these functions anywhere else is not really useful since the serial will be invalid outside of the touch down events (well it would work in the touch up event but that's just silly). Anyways, let's just make this work sanely. Eliminate the touch entries variable completely because it's pointless. Only one finger event is ever considered at a time. Touches besides the initial one are all ignored. If a user touches and drags within the touch edge radius, then a resize event occurs. If the user touches and drags elsewhere on the window, a move event occurs. A single tap displays the osc (which is clickable if you tap again). A double tap toggles fullscreen. Additionally, the default touch edge radius of 64 pixels is way too big (at least I think so). Cut this in half to 32 which feels a lot better (on a pinephone using plasma mobile anyway).
2021-08-08 05:05:05 +02:00
enum xdg_toplevel_resize_edge edge;
wayland: check for resize/move in touch event first 8300830951e2b0b90b22fc7d33b7556ed05e139c rearranged/simplified some of the wayland touch code mainly because what was there before was completely broken on my machine in those days (dragging was unreliable, resizing was really buggy, etc.). However, one user said that touch input no longer worked for him after that change. I could not ever reproduce it, but it seems the issue was putting down the key before testing for resize/move in the code. Now who knows why this actually matters, but apparently it works for the user in question and I don't observe any unexpected behavior on my end when swapping the order. Like the mouse/pointer code, we also now do a test for dragging before actually trying a resize/move which is a little more consistent than before. Fixes #9771.
2022-12-01 17:16:49 +01:00
if (!mp_input_test_dragging(wl->vo->input_ctx, wl->mouse_x, wl->mouse_y)) {
if (check_for_resize(wl, x_w, y_w, wl->opts->edge_pixels_touch, &edge)) {
xdg_toplevel_resize(wl->xdg_toplevel, wl->seat, serial, edge);
} else {
xdg_toplevel_move(wl->xdg_toplevel, wl->seat, serial);
}
wayland: improve behavior with touch events There's currently some touch related code in mpv wayland, but clearly nobody actually uses because it's a broken mess. Initially an attempt to distinguish between two finger touches and one finger touch was made, but there's not a good way to make this work. For whatever reason, initiating either xdg_toplevel_resize or xdg_toplevel_move blocks any other touch events from occurring (at least in plasma). Trying to call these functions anywhere else is not really useful since the serial will be invalid outside of the touch down events (well it would work in the touch up event but that's just silly). Anyways, let's just make this work sanely. Eliminate the touch entries variable completely because it's pointless. Only one finger event is ever considered at a time. Touches besides the initial one are all ignored. If a user touches and drags within the touch edge radius, then a resize event occurs. If the user touches and drags elsewhere on the window, a move event occurs. A single tap displays the osc (which is clickable if you tap again). A double tap toggles fullscreen. Additionally, the default touch edge radius of 64 pixels is way too big (at least I think so). Cut this in half to 32 which feels a lot better (on a pinephone using plasma mobile anyway).
2021-08-08 05:05:05 +02:00
}
wayland: check for resize/move in touch event first 8300830951e2b0b90b22fc7d33b7556ed05e139c rearranged/simplified some of the wayland touch code mainly because what was there before was completely broken on my machine in those days (dragging was unreliable, resizing was really buggy, etc.). However, one user said that touch input no longer worked for him after that change. I could not ever reproduce it, but it seems the issue was putting down the key before testing for resize/move in the code. Now who knows why this actually matters, but apparently it works for the user in question and I don't observe any unexpected behavior on my end when swapping the order. Like the mouse/pointer code, we also now do a test for dragging before actually trying a resize/move which is a little more consistent than before. Fixes #9771.
2022-12-01 17:16:49 +01:00
mp_input_set_mouse_pos(wl->vo->input_ctx, wl->mouse_x, wl->mouse_y);
mp_input_put_key(wl->vo->input_ctx, MP_MBTN_LEFT | MP_KEY_STATE_DOWN);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
static void touch_handle_up(void *data, struct wl_touch *wl_touch,
uint32_t serial, uint32_t time, int32_t id)
{
struct vo_wayland_state *wl = data;
mp_input_put_key(wl->vo->input_ctx, MP_MBTN_LEFT | MP_KEY_STATE_UP);
}
static void touch_handle_motion(void *data, struct wl_touch *wl_touch,
uint32_t time, int32_t id, wl_fixed_t x_w, wl_fixed_t y_w)
{
struct vo_wayland_state *wl = data;
wl->mouse_x = wl_fixed_to_int(x_w) * wl->scaling;
wl->mouse_y = wl_fixed_to_int(y_w) * wl->scaling;
mp_input_set_mouse_pos(wl->vo->input_ctx, wl->mouse_x, wl->mouse_y);
}
static void touch_handle_frame(void *data, struct wl_touch *wl_touch)
{
}
static void touch_handle_cancel(void *data, struct wl_touch *wl_touch)
{
}
static const struct wl_touch_listener touch_listener = {
touch_handle_down,
touch_handle_up,
touch_handle_motion,
touch_handle_frame,
touch_handle_cancel,
};
vo_wayland: share frame callbacks. Define frame callback logic in wayland_common.c As this should be used by opengl renderer as well. Preferably drawing should be skipped entierly when no frame callbacks are received. However, for now only swap buffers is skipped.
2015-03-22 01:47:27 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void keyboard_handle_keymap(void *data, struct wl_keyboard *wl_keyboard,
uint32_t format, int32_t fd, uint32_t size)
{
struct vo_wayland_state *wl = data;
char *map_str;
wayland: use a unified struct for the state This commit removes the pointer to the single different structures for input and window and puts them as anonymous structures inside the wayland_state structure. This has the disadvantage of passing the substructure to the listeners, but the advantage is that we don't have to allocate them and check for NULL pointers. This makes it more reliable and easier to follow.
2013-07-18 17:35:28 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (format != WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1) {
close(fd);
return;
}
wayland: use a unified struct for the state This commit removes the pointer to the single different structures for input and window and puts them as anonymous structures inside the wayland_state structure. This has the disadvantage of passing the substructure to the listeners, but the advantage is that we don't have to allocate them and check for NULL pointers. This makes it more reliable and easier to follow.
2013-07-18 17:35:28 +02:00
wayland: map keymaps with `MAP_PRIVATE` While mpv uses version 1 of the `wl_seat` protocol and `MAP_PRIVATE` is only required from version 7 on, using `MAP_PRIVATE` allows us to be compatible with compositors that have only been tested with newer applications. Since the keymap is not modified after `mmap`, using `MAP_SHARED` has no advantage over `MAP_PRIVATE`.
2022-01-07 23:26:18 +01:00
map_str = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (map_str == MAP_FAILED) {
close(fd);
return;
}
wayland: use a unified struct for the state This commit removes the pointer to the single different structures for input and window and puts them as anonymous structures inside the wayland_state structure. This has the disadvantage of passing the substructure to the listeners, but the advantage is that we don't have to allocate them and check for NULL pointers. This makes it more reliable and easier to follow.
2013-07-18 17:35:28 +02:00
wayland: use `xkb_keymap_new_from_buffer` Instead of `xkb_keymap_new_from_string`. The protocol does not require the keymap to be null terminated and if the size of the keymap is a multiple of the page size, using `_from_string` could lead to problems. Some compositors include a null byte and even include the null byte in `size`. Therefore we have to use `strnlen` to find the real length of the string. Note that `_from_string` internally uses `strlen` and then calls `_from_buffer`.
2022-01-07 23:28:02 +01:00
wl->xkb_keymap = xkb_keymap_new_from_buffer(wl->xkb_context, map_str,
strnlen(map_str, size),
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
XKB_KEYMAP_FORMAT_TEXT_V1, 0);
wayland: use a unified struct for the state This commit removes the pointer to the single different structures for input and window and puts them as anonymous structures inside the wayland_state structure. This has the disadvantage of passing the substructure to the listeners, but the advantage is that we don't have to allocate them and check for NULL pointers. This makes it more reliable and easier to follow.
2013-07-18 17:35:28 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
munmap(map_str, size);
close(fd);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if (!wl->xkb_keymap) {
Revert "wayland: don't create our own log context" This reverts commit beab54506e61bc080880e827e351439f76542e68. Conflicts: video/out/wayland_common.c
2013-09-12 16:29:13 +02:00
MP_ERR(wl, "failed to compile keymap\n");
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
return;
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl->xkb_state = xkb_state_new(wl->xkb_keymap);
if (!wl->xkb_state) {
Revert "wayland: don't create our own log context" This reverts commit beab54506e61bc080880e827e351439f76542e68. Conflicts: video/out/wayland_common.c
2013-09-12 16:29:13 +02:00
MP_ERR(wl, "failed to create XKB state\n");
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
xkb_keymap_unref(wl->xkb_keymap);
wl->xkb_keymap = NULL;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
return;
}
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void keyboard_handle_enter(void *data, struct wl_keyboard *wl_keyboard,
uint32_t serial, struct wl_surface *surface,
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
struct wl_array *keys)
{
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 18:22:25 +02:00
struct vo_wayland_state *wl = data;
wl->has_keyboard_input = true;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void keyboard_handle_leave(void *data, struct wl_keyboard *wl_keyboard,
uint32_t serial, struct wl_surface *surface)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 18:22:25 +02:00
struct vo_wayland_state *wl = data;
wl->has_keyboard_input = false;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void keyboard_handle_key(void *data, struct wl_keyboard *wl_keyboard,
uint32_t serial, uint32_t time, uint32_t key,
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
uint32_t state)
{
struct vo_wayland_state *wl = data;
wayland: check for modifier keys on pointer events The pointer button event had no code to handle any modifier keys. So this meant input combinations like Shift+MTBN_LEFT did not work. Fix this by ripping out the modifier-checking code in keyboard key event to a separate function and using it for both the keyboard and mouse events. In the case of the mouse, it is possible that the keyboard may not exist so be sure to check before trying to get any modifiers. Fixes #8239.
2020-11-07 20:47:26 +01:00
wl->keyboard_code = key + 8;
xkb_keysym_t sym = xkb_state_key_get_one_sym(wl->xkb_state, wl->keyboard_code);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: check for modifier keys on pointer events The pointer button event had no code to handle any modifier keys. So this meant input combinations like Shift+MTBN_LEFT did not work. Fix this by ripping out the modifier-checking code in keyboard key event to a separate function and using it for both the keyboard and mouse events. In the case of the mouse, it is possible that the keyboard may not exist so be sure to check before trying to get any modifiers. Fixes #8239.
2020-11-07 20:47:26 +01:00
state = state == WL_KEYBOARD_KEY_STATE_PRESSED ? MP_KEY_STATE_DOWN
: MP_KEY_STATE_UP;
int mpmod = get_mods(wl);
wayland: implement key modifiers Includes shift, ctrl, alt, meta.
2015-01-12 16:41:00 +01:00
int mpkey = lookupkey(sym);
if (mpkey) {
wayland: check for modifier keys on pointer events The pointer button event had no code to handle any modifier keys. So this meant input combinations like Shift+MTBN_LEFT did not work. Fix this by ripping out the modifier-checking code in keyboard key event to a separate function and using it for both the keyboard and mouse events. In the case of the mouse, it is possible that the keyboard may not exist so be sure to check before trying to get any modifiers. Fixes #8239.
2020-11-07 20:47:26 +01:00
mp_input_put_key(wl->vo->input_ctx, mpkey | state | mpmod);
wayland: implement key modifiers Includes shift, ctrl, alt, meta.
2015-01-12 16:41:00 +01:00
} else {
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
char s[128];
wayland: implement key modifiers Includes shift, ctrl, alt, meta.
2015-01-12 16:41:00 +01:00
if (xkb_keysym_to_utf8(sym, s, sizeof(s)) > 0)
wayland: check for modifier keys on pointer events The pointer button event had no code to handle any modifier keys. So this meant input combinations like Shift+MTBN_LEFT did not work. Fix this by ripping out the modifier-checking code in keyboard key event to a separate function and using it for both the keyboard and mouse events. In the case of the mouse, it is possible that the keyboard may not exist so be sure to check before trying to get any modifiers. Fixes #8239.
2020-11-07 20:47:26 +01:00
mp_input_put_key_utf8(wl->vo->input_ctx, state | mpmod, bstr0(s));
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void keyboard_handle_modifiers(void *data, struct wl_keyboard *wl_keyboard,
uint32_t serial, uint32_t mods_depressed,
uint32_t mods_latched, uint32_t mods_locked,
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
uint32_t group)
{
wayland: use a unified struct for the state This commit removes the pointer to the single different structures for input and window and puts them as anonymous structures inside the wayland_state structure. This has the disadvantage of passing the substructure to the listeners, but the advantage is that we don't have to allocate them and check for NULL pointers. This makes it more reliable and easier to follow.
2013-07-18 17:35:28 +02:00
struct vo_wayland_state *wl = data;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: check for xkb state in handle modifiers Normally in wayland, you receive a keymap event from the compositor which is what allows the client to setup what is needed for xkb. However, it turns out that this doesn't occur in the case of virtual keyboards, such as from wtype, that come from the custom virtual-keyboard protocol. What happens in this case is that mpv only receives a keyboard entrance event. According to the wayland protocol documentation [1], "the compositor must send wl_keyboard.modifiers event after [the wl_keyboard.enter] event". It is possible for this to occur before the physical keyboard is properly mapped (i.e: using a virtual keyboard to start mpv). What this results in is a segfault once xkb_state_update_mask is called in the modifiers event. The fix is to simply not always assume we have created the xkb state if we get this event and check for its existence first. Closes #9119. https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard
2021-08-15 16:32:11 +02:00
if (wl->xkb_state) {
xkb_state_update_mask(wl->xkb_state, mods_depressed, mods_latched,
mods_locked, 0, 0, group);
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void keyboard_handle_repeat_info(void *data, struct wl_keyboard *wl_keyboard,
int32_t rate, int32_t delay)
wayland: use reported rete and delay If native-keyrepeat is true then we set the rate and delay reported by the compositor.
2014-09-19 17:38:24 +02:00
{
struct vo_wayland_state *wl = data;
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
if (wl->vo_opts->native_keyrepeat)
wayland: use reported rete and delay If native-keyrepeat is true then we set the rate and delay reported by the compositor.
2014-09-19 17:38:24 +02:00
mp_input_set_repeat_info(wl->vo->input_ctx, rate, delay);
}
wayland: use static consistently Declare everything that is only needed inside wayland_common.c as static.
2014-01-08 16:15:26 +01:00
static const struct wl_keyboard_listener keyboard_listener = {
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
keyboard_handle_keymap,
keyboard_handle_enter,
keyboard_handle_leave,
keyboard_handle_key,
wayland: use reported rete and delay If native-keyrepeat is true then we set the rate and delay reported by the compositor.
2014-09-19 17:38:24 +02:00
keyboard_handle_modifiers,
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
keyboard_handle_repeat_info,
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
};
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void seat_handle_caps(void *data, struct wl_seat *seat,
enum wl_seat_capability caps)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
struct vo_wayland_state *wl = data;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if ((caps & WL_SEAT_CAPABILITY_POINTER) && !wl->pointer) {
wl->pointer = wl_seat_get_pointer(seat);
wl_pointer_add_listener(wl->pointer, &pointer_listener, wl);
} else if (!(caps & WL_SEAT_CAPABILITY_POINTER) && wl->pointer) {
wl_pointer_destroy(wl->pointer);
wl->pointer = NULL;
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if ((caps & WL_SEAT_CAPABILITY_KEYBOARD) && !wl->keyboard) {
wl->keyboard = wl_seat_get_keyboard(seat);
wl_keyboard_add_listener(wl->keyboard, &keyboard_listener, wl);
} else if (!(caps & WL_SEAT_CAPABILITY_KEYBOARD) && wl->keyboard) {
wl_keyboard_destroy(wl->keyboard);
wl->keyboard = NULL;
}
if ((caps & WL_SEAT_CAPABILITY_TOUCH) && !wl->touch) {
wl->touch = wl_seat_get_touch(seat);
wl_touch_set_user_data(wl->touch, wl);
wl_touch_add_listener(wl->touch, &touch_listener, wl);
} else if (!(caps & WL_SEAT_CAPABILITY_TOUCH) && wl->touch) {
wl_touch_destroy(wl->touch);
wl->touch = NULL;
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static const struct wl_seat_listener seat_listener = {
seat_handle_caps,
};
static void data_offer_handle_offer(void *data, struct wl_data_offer *offer,
const char *mime_type)
{
struct vo_wayland_state *wl = data;
int score = mp_event_get_mime_type_score(wl->vo->input_ctx, mime_type);
if (score > wl->dnd_mime_score) {
wl->dnd_mime_score = score;
talloc_free(wl->dnd_mime_type);
wl->dnd_mime_type = talloc_strdup(wl, mime_type);
MP_VERBOSE(wl, "Given DND offer with mime type %s\n", wl->dnd_mime_type);
}
}
wayland_common: organize and correctly map mouse buttons The function tried to do something clever but ignored the fact that the middle button followed the left button rather than the right. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
2017-03-17 07:25:32 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void data_offer_source_actions(void *data, struct wl_data_offer *offer, uint32_t source_actions)
{
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void data_offer_action(void *data, struct wl_data_offer *wl_data_offer, uint32_t dnd_action)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
struct vo_wayland_state *wl = data;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl->dnd_action = dnd_action & WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY ?
DND_REPLACE : DND_APPEND;
MP_VERBOSE(wl, "DND action is %s\n",
wl->dnd_action == DND_REPLACE ? "DND_REPLACE" : "DND_APPEND");
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static const struct wl_data_offer_listener data_offer_listener = {
data_offer_handle_offer,
data_offer_source_actions,
data_offer_action,
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
};
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void data_device_handle_data_offer(void *data, struct wl_data_device *wl_ddev,
struct wl_data_offer *id)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
struct vo_wayland_state *wl = data;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if (wl->dnd_offer)
wl_data_offer_destroy(wl->dnd_offer);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl->dnd_offer = id;
wl_data_offer_add_listener(id, &data_offer_listener, wl);
}
static void data_device_handle_enter(void *data, struct wl_data_device *wl_ddev,
uint32_t serial, struct wl_surface *surface,
wl_fixed_t x, wl_fixed_t y,
struct wl_data_offer *id)
{
struct vo_wayland_state *wl = data;
if (wl->dnd_offer != id) {
MP_FATAL(wl, "DND offer ID mismatch!\n");
return;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl_data_offer_set_actions(id, WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY |
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE,
WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY);
wl_data_offer_accept(id, serial, wl->dnd_mime_type);
MP_VERBOSE(wl, "Accepting DND offer with mime type %s\n", wl->dnd_mime_type);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void data_device_handle_leave(void *data, struct wl_data_device *wl_ddev)
wayland: use reported rete and delay If native-keyrepeat is true then we set the rate and delay reported by the compositor.
2014-09-19 17:38:24 +02:00
{
struct vo_wayland_state *wl = data;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if (wl->dnd_offer) {
if (wl->dnd_fd != -1)
return;
wl_data_offer_destroy(wl->dnd_offer);
wl->dnd_offer = NULL;
}
MP_VERBOSE(wl, "Releasing DND offer with mime type %s\n", wl->dnd_mime_type);
talloc_free(wl->dnd_mime_type);
wl->dnd_mime_type = NULL;
wl->dnd_mime_score = 0;
wayland: use reported rete and delay If native-keyrepeat is true then we set the rate and delay reported by the compositor.
2014-09-19 17:38:24 +02:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void data_device_handle_motion(void *data, struct wl_data_device *wl_ddev,
uint32_t time, wl_fixed_t x, wl_fixed_t y)
{
struct vo_wayland_state *wl = data;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl_data_offer_accept(wl->dnd_offer, time, wl->dnd_mime_type);
}
static void data_device_handle_drop(void *data, struct wl_data_device *wl_ddev)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
struct vo_wayland_state *wl = data;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
int pipefd[2];
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
if (pipe2(pipefd, O_CLOEXEC) == -1) {
MP_ERR(wl, "Failed to create dnd pipe!\n");
return;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
MP_VERBOSE(wl, "Receiving DND offer with mime %s\n", wl->dnd_mime_type);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl_data_offer_receive(wl->dnd_offer, wl->dnd_mime_type, pipefd[1]);
close(pipefd[1]);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl->dnd_fd = pipefd[0];
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static void data_device_handle_selection(void *data, struct wl_data_device *wl_ddev,
struct wl_data_offer *id)
{
wayland: partially fix drag and drop handling Drag and drop in wayland is weird and it seems everyone does this slightly differently (fun). In the past, there was a crash that occured (fixed by 700f4ef5fad353800fa866b059663bc1dd58d3b7) which involved using the wl_data_offer_finish in an incorrect way that triggered a protocol error (always fatal). The fix involved moving the function call to data_device_handle_drop which seemingly works, but it has an unfortunate side effect. It appears like GTK applications (or at least firefox) close the pipe after this function is called which makes it impossible for mpv to read data from the fd (well you could force it open again in theory but let's not do that). Who knows if that was the case when that commit was made (probably not because I'd think I would have noticed; could just be a dummy though), but obviously having broken dnd for a major application isn't so fun (this works with QT and chromium anyway). Ideally one would just simply check the pipe in data_device_handle_drop, but this doesn't work because it doesn't seem the compositor actually sends mpv the data by then. There's not actually a defined event when you're supposed to be able to read data from this pipe, so we wait for the usual event checking loop later for this. In that case, wl_data_offer_finish needs to go back into check_dnd_fd, but we have to be careful when calling it otherwise we'd just commit protocol errors like before. We check to make sure we even have a valid wl->dnd_offer before trying to indicate that it is finished and additionally make sure there is a valid dnd_action (after checking the fd, it's always set back to -1). This doesn't fix everything though. Specifically, sway with focus_follows_mouse (the default) and GTK as the data source still doesn't work. The reason is that when you do a drag and drop in sway with that option on, a new wl_data_device.data_offer event is sent out instantly after the drop event. This happens before any data is sent across the fd and before mpv even has a chance to check it. What GTK does, when getting this new data_offer event, is close the pipe (POLLHUP). This means mpv can't read it when we reach the event loop and thus no data is ever read and broken drag and drop. From the client side, this isn't really fixable since the wayland protocol doesn't have a clear indication of when clients are supposed to read from the fd and both the compositor and data source are doing things totally out of our control. So we'll consider this weird case, "not our bug" at least. The rest should work.
2022-02-03 17:48:56 +01:00
struct vo_wayland_state *wl = data;
if (wl->dnd_offer) {
wl_data_offer_destroy(wl->dnd_offer);
wl->dnd_offer = NULL;
wayland: add missing newline in wayland_common
2022-07-23 18:48:28 +02:00
MP_VERBOSE(wl, "Received a new DND offer. Releasing the previous offer.\n");
wayland: partially fix drag and drop handling Drag and drop in wayland is weird and it seems everyone does this slightly differently (fun). In the past, there was a crash that occured (fixed by 700f4ef5fad353800fa866b059663bc1dd58d3b7) which involved using the wl_data_offer_finish in an incorrect way that triggered a protocol error (always fatal). The fix involved moving the function call to data_device_handle_drop which seemingly works, but it has an unfortunate side effect. It appears like GTK applications (or at least firefox) close the pipe after this function is called which makes it impossible for mpv to read data from the fd (well you could force it open again in theory but let's not do that). Who knows if that was the case when that commit was made (probably not because I'd think I would have noticed; could just be a dummy though), but obviously having broken dnd for a major application isn't so fun (this works with QT and chromium anyway). Ideally one would just simply check the pipe in data_device_handle_drop, but this doesn't work because it doesn't seem the compositor actually sends mpv the data by then. There's not actually a defined event when you're supposed to be able to read data from this pipe, so we wait for the usual event checking loop later for this. In that case, wl_data_offer_finish needs to go back into check_dnd_fd, but we have to be careful when calling it otherwise we'd just commit protocol errors like before. We check to make sure we even have a valid wl->dnd_offer before trying to indicate that it is finished and additionally make sure there is a valid dnd_action (after checking the fd, it's always set back to -1). This doesn't fix everything though. Specifically, sway with focus_follows_mouse (the default) and GTK as the data source still doesn't work. The reason is that when you do a drag and drop in sway with that option on, a new wl_data_device.data_offer event is sent out instantly after the drop event. This happens before any data is sent across the fd and before mpv even has a chance to check it. What GTK does, when getting this new data_offer event, is close the pipe (POLLHUP). This means mpv can't read it when we reach the event loop and thus no data is ever read and broken drag and drop. From the client side, this isn't really fixable since the wayland protocol doesn't have a clear indication of when clients are supposed to read from the fd and both the compositor and data source are doing things totally out of our control. So we'll consider this weird case, "not our bug" at least. The rest should work.
2022-02-03 17:48:56 +01:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
static const struct wl_data_device_listener data_device_listener = {
data_device_handle_data_offer,
data_device_handle_enter,
data_device_handle_leave,
data_device_handle_motion,
data_device_handle_drop,
data_device_handle_selection,
};
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void output_handle_geometry(void *data, struct wl_output *wl_output,
int32_t x, int32_t y, int32_t phys_width,
int32_t phys_height, int32_t subpixel,
const char *make, const char *model,
int32_t transform)
wayland: handle multiple outputs more correctly There's a bit of a catch-22 in the wayland backend. mpv needs to know several things about the wl_output the surface is on (geometry, scale, etc.) for lots of its options. You still have to render something somewhere before you can know what wl_output the surface is actually on. So this means that when initializing the player, it is entirely possible to calculate initial parameters using the wrong wl_output. The surface listener is what will eventually correct this and pick the correct output. However not everything was technically working correctly in a multi-output setup. The first rule here is to rework find_output so that it returns a vo_wayland_output instead of internally setting wl->current_output. The reason is simply because the output found here is not guaranteed to be the output the surface is actually on. Note that for initialization of the player, we must set the output returned from this function as the wl->current_output even if it is not technically correct. The surface listener will fix it later. vo_wayland_reconfig has to confusingly serve two roles. It must ensure some wayland-related things are configured as well as setup things for mpv's vo. The various functions are shuffled around and some things are removed here which has subtle implications. For instance, there's no reason to always set the buffer scale. It only needs to be done once (when the wl->current_output is being created). A roundtrip needs to be done once after a wl_surface_commit to ensure there are no configuration errors. surface_handle_enter is now handles two different things: scaling as well as mpv's autofit/geometry options. When a surface enters a new output, the new scaling value is applied to all of the geometry-related structs (previously, this wasn't done). This ensures, in a multi-monitor case with mixed scale values, the surface is rescaled correctly to the actual output it is on if the initial selection of wl->current_output is incorrect. Additionally, autofit/geometry values are recalculated if they exist. This means that dragging a surface across different outputs will autofit correctly to the new output and not always be "stuck" on the old one. A very astute observer may notice that set_buffer_scale isn't set when the surface enters a new output. The API doesn't really indicate this, but a WAYLAND_DEBUG log reveals that the compositor (well at least sway/wlroots anyway) magically sets this for you. That's quite fortunate because setting in the surface handler caused all sorts of problems.
2020-12-07 00:34:36 +01:00
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_wayland_output *output = data;
output->make = talloc_strdup(output->wl, make);
output->model = talloc_strdup(output->wl, model);
output->geometry.x0 = x;
output->geometry.y0 = y;
output->phys_width = phys_width;
output->phys_height = phys_height;
wayland: handle multiple outputs more correctly There's a bit of a catch-22 in the wayland backend. mpv needs to know several things about the wl_output the surface is on (geometry, scale, etc.) for lots of its options. You still have to render something somewhere before you can know what wl_output the surface is actually on. So this means that when initializing the player, it is entirely possible to calculate initial parameters using the wrong wl_output. The surface listener is what will eventually correct this and pick the correct output. However not everything was technically working correctly in a multi-output setup. The first rule here is to rework find_output so that it returns a vo_wayland_output instead of internally setting wl->current_output. The reason is simply because the output found here is not guaranteed to be the output the surface is actually on. Note that for initialization of the player, we must set the output returned from this function as the wl->current_output even if it is not technically correct. The surface listener will fix it later. vo_wayland_reconfig has to confusingly serve two roles. It must ensure some wayland-related things are configured as well as setup things for mpv's vo. The various functions are shuffled around and some things are removed here which has subtle implications. For instance, there's no reason to always set the buffer scale. It only needs to be done once (when the wl->current_output is being created). A roundtrip needs to be done once after a wl_surface_commit to ensure there are no configuration errors. surface_handle_enter is now handles two different things: scaling as well as mpv's autofit/geometry options. When a surface enters a new output, the new scaling value is applied to all of the geometry-related structs (previously, this wasn't done). This ensures, in a multi-monitor case with mixed scale values, the surface is rescaled correctly to the actual output it is on if the initial selection of wl->current_output is incorrect. Additionally, autofit/geometry values are recalculated if they exist. This means that dragging a surface across different outputs will autofit correctly to the new output and not always be "stuck" on the old one. A very astute observer may notice that set_buffer_scale isn't set when the surface enters a new output. The API doesn't really indicate this, but a WAYLAND_DEBUG log reveals that the compositor (well at least sway/wlroots anyway) magically sets this for you. That's quite fortunate because setting in the surface handler caused all sorts of problems.
2020-12-07 00:34:36 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void output_handle_mode(void *data, struct wl_output *wl_output,
uint32_t flags, int32_t width,
int32_t height, int32_t refresh)
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_wayland_output *output = data;
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
/* Only save current mode */
if (!(flags & WL_OUTPUT_MODE_CURRENT))
return;
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
output->geometry.x1 = width;
output->geometry.y1 = height;
output->flags = flags;
output->refresh_rate = (double)refresh * 0.001;
}
wayland: update geometry/autofit opts on runtime Additionally, do some cleanups in the resize/autofitting code to make sure we don't do any wasteful VO_EVENT_RESIZE calls. Note that if set_geometry is called, we must always perform a resize.
2020-12-13 22:03:34 +01:00
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
static void output_handle_done(void *data, struct wl_output *wl_output)
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
{
struct vo_wayland_output *o = data;
struct vo_wayland_state *wl = o->wl;
wayland: handle multiple outputs more correctly There's a bit of a catch-22 in the wayland backend. mpv needs to know several things about the wl_output the surface is on (geometry, scale, etc.) for lots of its options. You still have to render something somewhere before you can know what wl_output the surface is actually on. So this means that when initializing the player, it is entirely possible to calculate initial parameters using the wrong wl_output. The surface listener is what will eventually correct this and pick the correct output. However not everything was technically working correctly in a multi-output setup. The first rule here is to rework find_output so that it returns a vo_wayland_output instead of internally setting wl->current_output. The reason is simply because the output found here is not guaranteed to be the output the surface is actually on. Note that for initialization of the player, we must set the output returned from this function as the wl->current_output even if it is not technically correct. The surface listener will fix it later. vo_wayland_reconfig has to confusingly serve two roles. It must ensure some wayland-related things are configured as well as setup things for mpv's vo. The various functions are shuffled around and some things are removed here which has subtle implications. For instance, there's no reason to always set the buffer scale. It only needs to be done once (when the wl->current_output is being created). A roundtrip needs to be done once after a wl_surface_commit to ensure there are no configuration errors. surface_handle_enter is now handles two different things: scaling as well as mpv's autofit/geometry options. When a surface enters a new output, the new scaling value is applied to all of the geometry-related structs (previously, this wasn't done). This ensures, in a multi-monitor case with mixed scale values, the surface is rescaled correctly to the actual output it is on if the initial selection of wl->current_output is incorrect. Additionally, autofit/geometry values are recalculated if they exist. This means that dragging a surface across different outputs will autofit correctly to the new output and not always be "stuck" on the old one. A very astute observer may notice that set_buffer_scale isn't set when the surface enters a new output. The API doesn't really indicate this, but a WAYLAND_DEBUG log reveals that the compositor (well at least sway/wlroots anyway) magically sets this for you. That's quite fortunate because setting in the surface handler caused all sorts of problems.
2020-12-07 00:34:36 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
o->geometry.x1 += o->geometry.x0;
o->geometry.y1 += o->geometry.y0;
MP_VERBOSE(o->wl, "Registered output %s %s (0x%x):\n"
"\tx: %dpx, y: %dpx\n"
"\tw: %dpx (%dmm), h: %dpx (%dmm)\n"
"\tscale: %d\n"
"\tHz: %f\n", o->make, o->model, o->id, o->geometry.x0,
o->geometry.y0, mp_rect_w(o->geometry), o->phys_width,
mp_rect_h(o->geometry), o->phys_height, o->scale, o->refresh_rate);
/* If we satisfy this conditional, something about the current
* output must have changed (resolution, scale, etc). All window
* geometry and scaling should be recalculated. */
if (wl->current_output && wl->current_output->output == wl_output) {
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
set_surface_scaling(wl);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
spawn_cursor(wl);
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
set_geometry(wl, false);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->pending_vo_events |= VO_EVENT_DPI;
wl->pending_vo_events |= VO_EVENT_RESIZE;
}
wl->pending_vo_events |= VO_EVENT_WIN_STATE;
}
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
static void output_handle_scale(void *data, struct wl_output *wl_output,
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
int32_t factor)
{
struct vo_wayland_output *output = data;
if (!factor) {
MP_ERR(output->wl, "Invalid output scale given by the compositor!\n");
return;
}
output->scale = factor;
}
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
#ifdef HAVE_WAYLAND_1_20
static void output_handle_name(void *data, struct wl_output *wl_output,
const char *name)
{
struct vo_wayland_output *output = data;
output->name = talloc_strdup(output->wl, name);
}
static void output_handle_description(void *data, struct wl_output *wl_output,
const char *description)
{
}
#endif
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const struct wl_output_listener output_listener = {
output_handle_geometry,
output_handle_mode,
output_handle_done,
output_handle_scale,
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
#ifdef HAVE_WAYLAND_1_20
output_handle_name,
output_handle_description,
#endif
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
};
static void surface_handle_enter(void *data, struct wl_surface *wl_surface,
struct wl_output *output)
{
struct vo_wayland_state *wl = data;
wayland: fix a potential segfault on surface enter This possibility actually existed for years. The wayland protocol is asynchronous and there's no restriction on when a compositor can send a surface enter event. In mpv's case, the surface enter event is used to set some vital things regarded geometry/scaling etc. However, this implictly assumes that wl->current_output is actually initialized. The vast majority of the time, vo_wayland_reconfig will happen first which is where wl->current_output is, and should, be created. There's no rule/law that the ordering of events will always occur in this order. Plasma with certain auto-profile conditions can send the surface enter event before mpv does its initial reconfig. That segfaults of course. Just add a check to make sure we have wl->current_output here and return if we don't. This assumes that the compositor will send us another surface enterance event when mpv actually does the initial surface commit and roundtrip request later. Wayland logs indicate this does happen. Fixes #9492.
2021-11-20 17:48:09 +01:00
if (!wl->current_output)
return;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct mp_rect old_output_geometry = wl->current_output->geometry;
struct mp_rect old_geometry = wl->geometry;
wl->current_output = NULL;
struct vo_wayland_output *o;
wl_list_for_each(o, &wl->output_list, link) {
if (o->output == output) {
wl->current_output = o;
break;
}
}
wl->current_output->has_surface = true;
bool force_resize = false;
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
if (!wl->fractional_scale_manager && wl->scaling != wl->current_output->scale) {
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
set_surface_scaling(wl);
spawn_cursor(wl);
wayland: always resize when scale changes on surface enter a02901cae77c86fb9de997a418296d1fc0e3eada changed how mpv was handling wl_surface_set_buffer_scale. It's correct in that constantly setting the surface scale on every resize (which mpv was previously doing) is unneccessary and not right. However, it introduced a slight regression if someone moved a surface to a new monitor with the same resolution but a different scale. It did not trigger a resize and thus the video would have incorrect dimensions. A later refactor changed how things looked inside here, but this regression wasn't fixed. A resize should always be triggered if the scale changes in this surface event. Fixes #9426.
2022-01-28 01:34:17 +01:00
force_resize = true;
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
wl->pending_vo_events |= VO_EVENT_DPI;
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!mp_rect_equals(&old_output_geometry, &wl->current_output->geometry)) {
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
set_geometry(wl, false);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
force_resize = true;
}
wayland: update geometry/autofit opts on runtime Additionally, do some cleanups in the resize/autofitting code to make sure we don't do any wasteful VO_EVENT_RESIZE calls. Note that if set_geometry is called, we must always perform a resize.
2020-12-13 22:03:34 +01:00
if (!mp_rect_equals(&old_geometry, &wl->geometry) || force_resize)
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wl->pending_vo_events |= VO_EVENT_RESIZE;
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
MP_VERBOSE(wl, "Surface entered output %s %s (0x%x), scale = %f, refresh rate = %f Hz\n",
wayland: also log refresh rate on surface entrance Never bothered to log this for some reason, but it's pretty convenient when debugging.
2022-11-18 23:36:21 +01:00
o->make, o->model, o->id, wl->scaling, o->refresh_rate);
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wl->pending_vo_events |= VO_EVENT_WIN_STATE;
}
static void surface_handle_leave(void *data, struct wl_surface *wl_surface,
struct wl_output *output)
{
struct vo_wayland_state *wl = data;
struct vo_wayland_output *o;
wl_list_for_each(o, &wl->output_list, link) {
if (o->output == output) {
o->has_surface = false;
wl->pending_vo_events |= VO_EVENT_WIN_STATE;
return;
}
}
}
static const struct wl_surface_listener surface_listener = {
surface_handle_enter,
surface_handle_leave,
};
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void xdg_wm_base_ping(void *data, struct xdg_wm_base *wm_base, uint32_t serial)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
xdg_wm_base_pong(wm_base, serial);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const struct xdg_wm_base_listener xdg_wm_base_listener = {
xdg_wm_base_ping,
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
};
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
static void handle_surface_config(void *data, struct xdg_surface *surface,
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
uint32_t serial)
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
{
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
xdg_surface_ack_configure(surface, serial);
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
}
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
static const struct xdg_surface_listener xdg_surface_listener = {
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
handle_surface_config,
};
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
static void handle_toplevel_config(void *data, struct xdg_toplevel *toplevel,
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
int32_t width, int32_t height, struct wl_array *states)
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
{
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
struct vo_wayland_state *wl = data;
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
struct mp_vo_opts *vo_opts = wl->vo_opts;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
struct mp_rect old_geometry = wl->geometry;
wayland: keep track of toplevel width/height again Regression from 24357cb. It's ugly but unfortunately keeping tracking of the last toplevel width and height really is the best way to solve this problem and removing it was a mistake. Compositors don't always send width/height coordinates of the actual window. The easiest way to trigger this is by changing window-scale/current-window-scale and then unfocusing the window. The compositor will send another toplevel configure event with coordinates of the window before the resize. Maybe compositors could be smarter but multiple ones do this (sway, gnome, plasma), so just keep the old workaround. The only difference this time is that the toplevel width/height is saved at the very beginning which also covers the case where it equals 0 (i.e. weston).
2021-08-06 18:47:16 +02:00
int old_toplevel_width = wl->toplevel_width;
int old_toplevel_height = wl->toplevel_height;
wl->toplevel_width = width;
wl->toplevel_height = height;
Revert "wayland: ignore 0x0 resizes" So actually according to the xdg-shell spec, a 0x0 resize is meant to indicate that "the client should decide its own window dimension". Previously, this just accidentally worked. In mutter 41.3, they changed how 0x0 resizes were sent and what actually happened was that mpv tried to resize itself to 0x0. This was obviously broken, so the reverted commit naively just ignored 0x0. It actually seemed to work, but it ended up breaking older versions of mutter. It's also not exactly the correct fix so it deserves a revert. This reverts commit d16defac27fcfe3e5fc43af6e42c2e590988cd3d. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
2022-01-25 18:48:43 +01:00
/* Don't do anything here if we haven't finished setting geometry. */
if (mp_rect_w(wl->geometry) == 0 || mp_rect_h(wl->geometry) == 0)
wayland: ignore toplevel listener if geometry is 0 It turns out that if a user specifies fullscreen=yes and a width/height in an autoprofile, the compositor can execute its toplevel listener event. This can happen before we have any mpv window rendered at all so we end up performing a bunch of geometry operations and state checks when we shouldn't. It subtly messes up a lot of things like state detection. Just return from this function if the geometry has no width or height yet.
2021-04-25 18:40:49 +02:00
return;
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
bool is_maximized = false;
bool is_fullscreen = false;
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 18:22:25 +02:00
bool is_activated = false;
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
enum xdg_toplevel_state *state;
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wl_array_for_each(state, states) {
switch (*state) {
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
case XDG_TOPLEVEL_STATE_FULLSCREEN:
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
is_fullscreen = true;
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
break;
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
case XDG_TOPLEVEL_STATE_RESIZING:
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
break;
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
case XDG_TOPLEVEL_STATE_ACTIVATED:
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 18:22:25 +02:00
is_activated = true;
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
/*
* If we get an ACTIVATED state, we know it cannot be
wayland: toplevel config fixes There were a couple of erroneous things in the handle_toplevel_config function. Firstly, looping through the different states was not handled correctly. Launching a window as maximized (can happen in sway for example) was always stuck on true and would never be set to false. Fix this by always checking if XDG_TOPLEVEL_STATE_MAXIMIZED is found or not. Also do a similar thing for the fullscreen state. Additionally, there were some issues with resizing windows and window-scale going back to old sizes. The root of this problem is that the width and height arguments of handle_toplevel_config aren't actually guarenteed to be the actual width and height of the surface. There are times when mpv will set the surface size on its own (like with window-scale) which will be unknown to the toplevel listener. To complicate matters, there are times when we do want to use the width and height arguments (like when resizing with the mouse). Fix this by checking if the width and height arguments reported by handle_toplevel_config changed from the previous call of the function. If the value is different, then we go ahead and use them when setting mpv's geometry. If not, then we just ignore it.
2020-02-06 03:47:10 +01:00
* minimized, but it may not have been minimized
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
* previously, so we can't detect the exact state.
*/
vo_opts->window_minimized = false;
m_config_cache_write_opt(wl->vo_opts_cache,
&vo_opts->window_minimized);
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
break;
wayland_common: fix maximized state Window size should not change if the window has been maximized or tiled.
2018-05-15 21:20:16 +02:00
case XDG_TOPLEVEL_STATE_TILED_TOP:
case XDG_TOPLEVEL_STATE_TILED_LEFT:
case XDG_TOPLEVEL_STATE_TILED_RIGHT:
case XDG_TOPLEVEL_STATE_TILED_BOTTOM:
case XDG_TOPLEVEL_STATE_MAXIMIZED:
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
is_maximized = true;
wayland_common: fix maximized state Window size should not change if the window has been maximized or tiled.
2018-05-15 21:20:16 +02:00
break;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
}
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
if (vo_opts->fullscreen != is_fullscreen) {
wl->state_change = true;
vo_opts->fullscreen = is_fullscreen;
m_config_cache_write_opt(wl->vo_opts_cache, &vo_opts->fullscreen);
}
if (vo_opts->window_maximized != is_maximized) {
wl->state_change = true;
vo_opts->window_maximized = is_maximized;
m_config_cache_write_opt(wl->vo_opts_cache, &vo_opts->window_maximized);
}
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
if (wl->requested_decoration)
request_decoration_mode(wl, wl->requested_decoration);
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 18:22:25 +02:00
if (wl->activated != is_activated) {
wl->activated = is_activated;
if ((!wl->focused && wl->activated && wl->has_keyboard_input) ||
(wl->focused && !wl->activated))
{
wl->focused = !wl->focused;
wl->pending_vo_events |= VO_EVENT_FOCUS;
}
wayland: cleanup handle_toplevel_config The source of many geometry woes. There's some loosely related toplevel things that should be cleaned up/fixed. First of all, VO_EVENT_LIVE_RESIZING is actually completely useless. It might have been useful sometime in the past, but there's no point. It doesn't "speed up" resizing in any way and appears to be originally for cocoa. Just remove it. Way back in the day, toplevel_width/height was added as a workaround for when we got uncoorperative (i.e. wrong) width/height coordinates from the compositor in this event. Basically it could happen due to numerous reasons but a lack of atomic commits was part of the reason and also mpv's geometry handling then was a lot rougher. We *shouldn't* need this workaround anymore. The width/height values are only used exactly when we need them. If mpv sets geometry on its own, it should still be the right dimensions. Related to the above, mpv never actually propertly handled the case where width or height was equal to 0. According to the xdg-shell spec, "If the width or height arguments are zero, it means the client should decided its own window dimension." An example of a compositor doing this is weston. It's, unsurprisingly, broken. Getting out of fullscreen or a maximized state does not restore the old window size like it should. The right way to handle this is to just return near the end of the function if we have a 0 for either argument and before any geometry is set (wl->geometry's width or height can never be zero). Luckily, state changes are already being detected so they just trigger the goto when needed. Finally, e2c24ad mistakenly removed the VO_EVENT_EXPOSE. There are edge cases where this is needed and it's safer to just force a redraw here when the window gets activated again. Just force wl->hidden to false first and then trigger the expose.
2021-08-02 23:49:48 +02:00
/* Just force a redraw to be on the safe side. */
if (wl->activated) {
wl->hidden = false;
wl->pending_vo_events |= VO_EVENT_EXPOSE;
}
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 18:22:25 +02:00
}
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
if (wl->state_change) {
if (!is_fullscreen && !is_maximized) {
wl->geometry = wl->window_size;
wl->state_change = false;
goto resize;
}
}
wayland_common: reset the LIVE_RESIZING flag when resizing ends The VO code resets each flag individually, and it doesn't do it for this one. Also make the prints use the struct names rather than the hardcoded ones, forgot to add those to the last wayland_common commit.
2017-10-05 16:34:48 +02:00
wayland: actually handle 0x0 resizes correctly According to the xdg-shell protocol spec, a 0x0 size from the compositor means that "the client should decide its own window dimension". We were not doing this correctly. What should happen is that mpv should simply reuse the old window size if it is not maximized or fullscreened. This should work on all (reasonably recent) versions of mutter and an compositor that follows the spec. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
2022-01-25 18:56:37 +01:00
/* Reuse old size if either of these are 0. */
if (width == 0 || height == 0) {
if (!is_fullscreen && !is_maximized) {
wl->geometry = wl->window_size;
}
goto resize;
}
wayland: keep track of toplevel width/height again Regression from 24357cb. It's ugly but unfortunately keeping tracking of the last toplevel width and height really is the best way to solve this problem and removing it was a mistake. Compositors don't always send width/height coordinates of the actual window. The easiest way to trigger this is by changing window-scale/current-window-scale and then unfocusing the window. The compositor will send another toplevel configure event with coordinates of the window before the resize. Maybe compositors could be smarter but multiple ones do this (sway, gnome, plasma), so just keep the old workaround. The only difference this time is that the toplevel width/height is saved at the very beginning which also covers the case where it equals 0 (i.e. weston).
2021-08-06 18:47:16 +02:00
if (old_toplevel_width == wl->toplevel_width &&
old_toplevel_height == wl->toplevel_height)
wayland: toplevel config fixes There were a couple of erroneous things in the handle_toplevel_config function. Firstly, looping through the different states was not handled correctly. Launching a window as maximized (can happen in sway for example) was always stuck on true and would never be set to false. Fix this by always checking if XDG_TOPLEVEL_STATE_MAXIMIZED is found or not. Also do a similar thing for the fullscreen state. Additionally, there were some issues with resizing windows and window-scale going back to old sizes. The root of this problem is that the width and height arguments of handle_toplevel_config aren't actually guarenteed to be the actual width and height of the surface. There are times when mpv will set the surface size on its own (like with window-scale) which will be unknown to the toplevel listener. To complicate matters, there are times when we do want to use the width and height arguments (like when resizing with the mouse). Fix this by checking if the width and height arguments reported by handle_toplevel_config changed from the previous call of the function. If the value is different, then we go ahead and use them when setting mpv's geometry. If not, then we just ignore it.
2020-02-06 03:47:10 +01:00
return;
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
if (!is_fullscreen && !is_maximized) {
wayland: fix keepaspect-window during resize So the resizing mechanism is actually supposed to match the video size to the window size while preserving the aspect ratio. In wayland, the current logic behaves as if --no-keepaspect-window was set. Fix this by simply multiplying the height by the same scale factor the width is multiplied by. Also get rid of the pointless (width > height) test (it makes no difference in any case) as well as some unneccesary checks for the keepaspect-window option. The use of ceil here is to make sure the window coordinates can never possibly have be 0 due to truncation (weston can still give you a 1x1 window which is fun). Fixes #9098.
2021-08-09 03:55:26 +02:00
if (vo_opts->keepaspect) {
double scale_factor = (double)width / wl->reduced_width;
width = ceil(wl->reduced_width * scale_factor);
if (vo_opts->keepaspect_window)
height = ceil(wl->reduced_height * scale_factor);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
wl->window_size.x0 = 0;
wl->window_size.y0 = 0;
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
wl->window_size.x1 = round(width * wl->scaling);
wl->window_size.y1 = round(height * wl->scaling);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
wl->geometry.x0 = 0;
wl->geometry.y0 = 0;
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
wl->geometry.x1 = round(width * wl->scaling);
wl->geometry.y1 = round(height * wl->scaling);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
if (mp_rect_equals(&old_geometry, &wl->geometry))
return;
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
resize:
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
MP_VERBOSE(wl, "Resizing due to xdg from %ix%i to %ix%i\n",
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
mp_rect_w(old_geometry), mp_rect_h(old_geometry),
mp_rect_w(wl->geometry), mp_rect_h(wl->geometry));
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl->pending_vo_events |= VO_EVENT_RESIZE;
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
wl->toplevel_configured = true;
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
}
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
static void handle_toplevel_close(void *data, struct xdg_toplevel *xdg_toplevel)
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
{
wayland_common: respect close events Overlooked. Also add a comment and only set the parent if WinID is set.
2017-10-05 17:43:44 +02:00
struct vo_wayland_state *wl = data;
mp_input_put_key(wl->vo->input_ctx, MP_KEY_CLOSE_WIN);
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
}
wayland: add support for configure bounds In wayland-protocols 1.25, xdg-shell got a version bump which added the configure_bounds event. The compositor can send this to clients to indicate that they should not resize past a certain size. For mpv, we'll choose to only listen to this on reconfig events (i.e. when the window first appears and if the video resolution changes later in the playlist). However, this behavior is still exposed as a user option (default on) because it will neccesarily conflict with a user setting a specific geometry size and/or window scale. Presumably, if someone is setting a really large size that goes beyond the bounds of their monitor, they actually want it like that. The wayland-protocols version is newer-ish, but we can get around having to poke the build system by just using a define that exists in the generated xdg-shell header.
2022-05-31 15:36:15 +02:00
#ifdef XDG_TOPLEVEL_CONFIGURE_BOUNDS_SINCE_VERSION
static void handle_configure_bounds(void *data, struct xdg_toplevel *xdg_toplevel,
int32_t width, int32_t height)
{
struct vo_wayland_state *wl = data;
wl->bounded_width = width;
wl->bounded_height = height;
}
#endif
wayland_common: update to stable xdg-shell This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
2018-04-23 16:10:40 +02:00
static const struct xdg_toplevel_listener xdg_toplevel_listener = {
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
handle_toplevel_config,
handle_toplevel_close,
wayland: add support for configure bounds In wayland-protocols 1.25, xdg-shell got a version bump which added the configure_bounds event. The compositor can send this to clients to indicate that they should not resize past a certain size. For mpv, we'll choose to only listen to this on reconfig events (i.e. when the window first appears and if the video resolution changes later in the playlist). However, this behavior is still exposed as a user option (default on) because it will neccesarily conflict with a user setting a specific geometry size and/or window scale. Presumably, if someone is setting a really large size that goes beyond the bounds of their monitor, they actually want it like that. The wayland-protocols version is newer-ish, but we can get around having to poke the build system by just using a define that exists in the generated xdg-shell header.
2022-05-31 15:36:15 +02:00
#ifdef XDG_TOPLEVEL_CONFIGURE_BOUNDS_SINCE_VERSION
handle_configure_bounds,
#endif
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
};
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_31
static void preferred_scale(void *data,
struct wp_fractional_scale_v1 *fractional_scale,
uint32_t scale)
{
struct vo_wayland_state *wl = data;
double old_scale = wl->scaling;
// dmabuf_wayland is always wl->scaling = 1
bool dmabuf_wayland = !strcmp(wl->vo->driver->name, "dmabuf-wayland");
wl->scaling = !dmabuf_wayland ? (double)scale / 120 : 1;
MP_VERBOSE(wl, "Obtained preferred scale, %f, from the compositor.\n",
wl->scaling);
wl->pending_vo_events |= VO_EVENT_DPI;
if (wl->current_output) {
rescale_geometry(wl, old_scale);
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
set_geometry(wl, false);
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
wl->pending_vo_events |= VO_EVENT_RESIZE;
}
}
static const struct wp_fractional_scale_v1_listener fractional_scale_listener = {
preferred_scale,
};
#endif
video/out/wayland_common: clear decoration request even if compositor disagrees Otherwise mpv and the compositor can end up in an eternal loop where mpv requests one mode, and compositor tells that the mode is not that (and will most likely not change). Additionally, log these mismatches - first time as a warning, and later as debug logging.
2022-10-22 18:00:25 +02:00
static const char *zxdg_decoration_mode_to_str(const uint32_t mode)
{
switch (mode) {
case ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE:
return "server-side";
case ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE:
return "client-side";
default:
return "<unknown>";
}
}
wayland: handle xdg-decoration protocol better The current usage of the xdg-decoration protocol is quite a bit crude. There's a specific listener struct for this like with most wayland things, but mpv wasn't even using it. It also made no attempt to detect if the compositor was telling mpv to use client side decorations. To implement this correctly, first of all we need to create the decoration listener object and add it like how most wayland things work. Secondly, set_border_decorations needs to be changed to accept the uint32_t mode given by the compositor. When we get the decoration event, pass the mode obtained from the compositor to set_border_decorations. Update the mpv border option, based on whether or not we have server side decorations (yes if we have them; no if we don't). mpv can actually request either client side or server side decorations with this protocol. This function doesn't belong in set_border_decorations but rather it should be called when the border option changes. Whether or not this request actually works depends on the compositor (Plasma appears to allow it; sway does not). If the compositor allows this request, then it gets handled by configure_decorations. Note that the enum strangely starts at 1 hence why there is an extra +1.
2021-08-09 18:40:46 +02:00
static void configure_decorations(void *data,
struct zxdg_toplevel_decoration_v1 *xdg_toplevel_decoration,
uint32_t mode)
{
struct vo_wayland_state *wl = data;
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
struct mp_vo_opts *opts = wl->vo_opts;
video/out/wayland_common: adjust decoration disagreement log level Originally, I considered warning once to be useful for figuring out whether the change in logic regarding resetting requested mode actually fixed the reported issue or not, but alas not everyone was happy with that decision. Thus the log level will always be debug. This enables us to lose one level of indent as well as a variable, which is always positive. Additionally, make the message more explicit regarding what could possibly be implied by the mismatch, as it seems like this was not always clear.
2022-10-26 22:37:48 +02:00
if (wl->requested_decoration && mode != wl->requested_decoration) {
MP_DBG(wl,
"Requested %s decorations but compositor responded with %s. "
"It is likely that compositor wants us to stay in a given mode.\n",
zxdg_decoration_mode_to_str(wl->requested_decoration),
zxdg_decoration_mode_to_str(mode));
video/out/wayland_common: clear decoration request even if compositor disagrees Otherwise mpv and the compositor can end up in an eternal loop where mpv requests one mode, and compositor tells that the mode is not that (and will most likely not change). Additionally, log these mismatches - first time as a warning, and later as debug logging.
2022-10-22 18:00:25 +02:00
}
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
video/out/wayland_common: adjust decoration disagreement log level Originally, I considered warning once to be useful for figuring out whether the change in logic regarding resetting requested mode actually fixed the reported issue or not, but alas not everyone was happy with that decision. Thus the log level will always be debug. This enables us to lose one level of indent as well as a variable, which is always positive. Additionally, make the message more explicit regarding what could possibly be implied by the mismatch, as it seems like this was not always clear.
2022-10-26 22:37:48 +02:00
wl->requested_decoration = 0;
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
if (mode == ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE) {
MP_VERBOSE(wl, "Enabling server decorations\n");
} else {
MP_VERBOSE(wl, "Disabling server decorations\n");
}
video/out/wayland_common: make decoration state usage explicit It is verbose, but makes it more explicit that requested_decoration takes in three values: * 0: no specific mode requested by mpv * ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border) * ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
2022-10-22 11:50:18 +02:00
opts->border = mode == ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE;
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
m_config_cache_write_opt(wl->vo_opts_cache, &opts->border);
wayland: handle xdg-decoration protocol better The current usage of the xdg-decoration protocol is quite a bit crude. There's a specific listener struct for this like with most wayland things, but mpv wasn't even using it. It also made no attempt to detect if the compositor was telling mpv to use client side decorations. To implement this correctly, first of all we need to create the decoration listener object and add it like how most wayland things work. Secondly, set_border_decorations needs to be changed to accept the uint32_t mode given by the compositor. When we get the decoration event, pass the mode obtained from the compositor to set_border_decorations. Update the mpv border option, based on whether or not we have server side decorations (yes if we have them; no if we don't). mpv can actually request either client side or server side decorations with this protocol. This function doesn't belong in set_border_decorations but rather it should be called when the border option changes. Whether or not this request actually works depends on the compositor (Plasma appears to allow it; sway does not). If the compositor allows this request, then it gets handled by configure_decorations. Note that the enum strangely starts at 1 hence why there is an extra +1.
2021-08-09 18:40:46 +02:00
}
static const struct zxdg_toplevel_decoration_v1_listener decoration_listener = {
configure_decorations,
};
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void pres_set_clockid(void *data, struct wp_presentation *pres,
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 18:05:00 +02:00
uint32_t clockid)
wayland: reworked resizing This fixes 2 bugs: * Resizing very fast breaks the aspect of the window and the width and height don't match with the video anymore * Pressing 'f' for fullscreen very fast can overwrite the backup variables for the previous width and height. Also includes a better aspect calculation with fluid resizing.
2013-05-07 20:51:09 +02:00
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_wayland_state *wl = data;
wayland/egl: rework resizing (again) Moves a good chunk of the resizing code to wayland_common.c. This makes it possible to share it with future video drivers. It doesn't resizit it immediatly, it calcutlates the new position and size and then shedules a resizing event. This removes the ugly callback and void pointer from the wayland data structure.
2013-08-23 11:29:09 +02:00
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 18:05:00 +02:00
if (clockid == CLOCK_MONOTONIC || clockid == CLOCK_MONOTONIC_RAW)
wl->use_present = true;
wayland: reworked resizing This fixes 2 bugs: * Resizing very fast breaks the aspect of the window and the width and height don't match with the video anymore * Pressing 'f' for fullscreen very fast can overwrite the backup variables for the previous width and height. Also includes a better aspect calculation with fluid resizing.
2013-05-07 20:51:09 +02:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const struct wp_presentation_listener pres_listener = {
pres_set_clockid,
};
static void feedback_sync_output(void *data, struct wp_presentation_feedback *fback,
struct wl_output *output)
wayland: expose wayland-app-id as a user option This is extremely similar to x11's WM_CLASS. This commit allows users to set mpv's app-id at runtime for any of the wayland backends.
2020-08-12 16:51:51 +02:00
{
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void feedback_presented(void *data, struct wp_presentation_feedback *fback,
uint32_t tv_sec_hi, uint32_t tv_sec_lo,
uint32_t tv_nsec, uint32_t refresh_nsec,
uint32_t seq_hi, uint32_t seq_lo,
uint32_t flags)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
struct vo_wayland_feedback_pool *fback_pool = data;
struct vo_wayland_state *wl = fback_pool->wl;
wayland: remove KDE server-decoration support
2018-11-10 19:45:58 +01:00
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
if (fback)
remove_feedback(fback_pool, fback);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->refresh_interval = (int64_t)refresh_nsec / 1000;
// Very similar to oml_sync_control, in this case we assume that every
// time the compositor receives feedback, a buffer swap has been already
// been performed.
//
// Notes:
// - tv_sec_lo + tv_sec_hi is the equivalent of oml's ust
// - seq_lo + seq_hi is the equivalent of oml's msc
// - these values are updated everytime the compositor receives feedback.
int64_t sec = (uint64_t) tv_sec_lo + ((uint64_t) tv_sec_hi << 32);
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 18:49:28 +02:00
int64_t ust = sec * 1000000LL + (uint64_t) tv_nsec / 1000;
int64_t msc = (uint64_t) seq_lo + ((uint64_t) seq_hi << 32);
present_update_sync_values(wl->present, ust, msc);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: silence annoying libwayland-client message libwayland-client contains the following code [1]: runtime_dir = getenv("XDG_RUNTIME_DIR"); if (!runtime_dir) { fprintf(stderr, "error: XDG_RUNTIME_DIR not set in the environment.\n"); This means this message will unconditionally and unavoidably be printed if XDG_RUNTIME_DIR is not set. Since mpv is a terminal program, and we want to avoid unnecessary output, work it around by not attempting to use wayland if this environment variable is not set. [1] http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n636 (cd0dccd01e16fa404e03974d30ded3aebdb1c4bc)
2014-01-07 01:06:28 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void feedback_discarded(void *data, struct wp_presentation_feedback *fback)
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
{
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
struct vo_wayland_feedback_pool *fback_pool = data;
if (fback)
remove_feedback(fback_pool, fback);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const struct wp_presentation_feedback_listener feedback_listener = {
feedback_sync_output,
feedback_presented,
feedback_discarded,
};
gl_common: signal to GL backend whether we are probing This is supposed to reduce the amount of useless error messages shown during initialization of vo_opengl. If multiple backends are compiled, usually only one of them will work. For example, on Linux both X and Wayland backends can be compiled, but usually either Wayland or X is running. Then, if Wayland is not running, but X is, trying to initialize the Wayland backend should not spam the terminal with error messages. Signed-off-by: Andreas Sinz <andreas.sinz@aon.at>
2013-09-10 18:33:43 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const struct wl_callback_listener frame_listener;
wayland_common: init output_list during main struct init Otherwise if display connection or xkb init failed the uninit function could segfault.
2017-10-13 00:14:05 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void frame_callback(void *data, struct wl_callback *callback, uint32_t time)
{
struct vo_wayland_state *wl = data;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (callback)
wl_callback_destroy(callback);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->frame_callback = wl_surface_frame(wl->surface);
wl_callback_add_listener(wl->frame_callback, &frame_listener, wl);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: consistently employ use_present We have a use_present bool that keeps track of whether or not to use presentation time. However, the creation of the feedback listener actually wasn't checking this and was instead checking for the existence of wl->presentation. There's no point in always creating the listener and feedback if mpv isn't actually going to use it. Just change it to use_present instead.
2023-01-01 04:06:38 +01:00
if (wl->use_present) {
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
struct wp_presentation_feedback *fback = wp_presentation_feedback(wl->presentation, wl->surface);
add_feedback(wl->fback_pool, fback);
wp_presentation_feedback_add_listener(fback, &feedback_listener, wl->fback_pool);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->frame_wait = false;
wayland: unset hidden state in frame callback More wayland weirdness. So previously, flipping a hidden state from true to false was done in vo_wayland_wait_frame. In theory, this would be after you get the frame callback and all those events so there's no problem. However since the function also does a bunch of flushing/dispatching/etc. to the default display queue so a lot of unknown things can happen before we actually set the hidden variable back to false. For example if a single image was paused and left on another virtual desktop long enough (~5 minutes) while also not having focus, switching back to that desktop could render it a black frame. This edge case was supposed to be handled by the surface being activated again in the toplevel event but apparently that doesn't always work. The fix is to just delete all of that junk and set wl->hidden = false in the frame callback. What's actually happening is kind of a mystery honestly. Probably the compositor drops the buffers after a while as an optimization (sensible) and forces a repaint if you switch back to the virtual desktop. Somehow wl->hidden not being set to false would not properly trigger a repaint (likely because it also sends a toplevel event which does stuff) thus you just get a black window. If you just make sure to set hidden in the frame callback, it appears like all of these problems and edge cases are solved. Since this event must happen first, that makes sense. That simplifies a lot of stuff and fixes some subtle bugs at the same time so just go with this approach.
2021-07-26 21:26:51 +02:00
wl->hidden = false;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
static const struct wl_callback_listener frame_listener = {
frame_callback,
};
Revert "vo_dmabuf_wayland: drop support for linux-dmabuf-v2" This was originally dropped because it was thought to be unneeded at the time, but at least some devices (rockchip) apparently are still on old compositors that use linux-dmabuf v2. It's not much code, and for testing purposes it's good to have around since it's hard to test drmprime otherwise. Some minor additions are here to support the newly added vaapi-format mapping in v2 of the protocol. This reverts commit a5b9d529eec8d4bb6fc858143337c3573ec8afd0.
2023-02-17 18:24:15 +01:00
static void dmabuf_format(void *data, struct zwp_linux_dmabuf_v1 *zwp_linux_dmabuf,
uint32_t format)
{
struct vo_wayland_state *wl = data;
if (wl->drm_format_ct == wl->drm_format_ct_max) {
wl->drm_format_ct_max *= 2;
wl->drm_formats = talloc_realloc(wl, wl->drm_formats, int, wl->drm_format_ct_max);
}
wl->drm_formats[wl->drm_format_ct++] = format;
MP_VERBOSE(wl, "%s is supported by the compositor.\n", mp_tag_str(format));
}
static const struct zwp_linux_dmabuf_v1_listener dmabuf_listener = {
dmabuf_format
};
build: add an additional check for wayland-protocols 1.24 666cb91cf12a4f8b42087530104513b0fc4ba16d added support for v4 of the dmabuf protocol. This was meant to be optional and the fallback support for the old v2 (dates back to 2017[0] well before the 1.15 wayland-protocol version we depend on) was maintained. However, v4 added several new functions and structs that of course aren't defined in old protocol versions so naturally this breaks the build on those systems. Since this is just a niche feature and not really critical to overall wayland support in mpv, just give in and add another check in the build system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf depends on wayland protocols 1-24[1], so go ahead and make that our new check. Fixes #10807. [0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4 [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
2022-10-29 20:07:34 +02:00
#if HAVE_WAYLAND_PROTOCOLS_1_24
wayland: bump dmabuf protocol to version 4 Pulled from https://github.com/mpv-player/mpv/pull/10382 The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor containing both formats and modifiers, which makes it possible for the compositor to import the buffers onto planes using explicit modifiers. This is an extremely important efficiency improvement, as the 3D hardware can be left powered off altogether, the vaapi buffer being sent directly from the video hardware to the display controller. It could be possible to support zwp_linux_dmabuf_v1 version 3 as well, but there is no reason beyond compatibility with old stacks. I would recommend to ditch version 2 as well, as modifier-less formats aren’t very useful nowadays.
2022-07-07 12:03:21 +02:00
static void done(void *data,
struct zwp_linux_dmabuf_feedback_v1 *zwp_linux_dmabuf_feedback_v1)
vo_vaapi_wayland/wayland_common: code style fixes A bad person (AKA me) merged this stuff without paying close enough attention to the code style. Reformat this to be in-line with the rest of the wayland code and general mpv style (braces for functions on the next line, horizontally aligning arguments, some cosmetic cleanups for wayland_common.h, etc.).
2022-05-30 19:58:57 +02:00
{
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
}
wayland: bump dmabuf protocol to version 4 Pulled from https://github.com/mpv-player/mpv/pull/10382 The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor containing both formats and modifiers, which makes it possible for the compositor to import the buffers onto planes using explicit modifiers. This is an extremely important efficiency improvement, as the 3D hardware can be left powered off altogether, the vaapi buffer being sent directly from the video hardware to the display controller. It could be possible to support zwp_linux_dmabuf_v1 version 3 as well, but there is no reason beyond compatibility with old stacks. I would recommend to ditch version 2 as well, as modifier-less formats aren’t very useful nowadays.
2022-07-07 12:03:21 +02:00
static void format_table(void *data,
struct zwp_linux_dmabuf_feedback_v1 *zwp_linux_dmabuf_feedback_v1,
int32_t fd,
uint32_t size)
{
struct vo_wayland_state *wl = data;
void *map = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map != MAP_FAILED) {
wl->format_map = map;
wl->format_size = size;
}
}
static void main_device(void *data,
struct zwp_linux_dmabuf_feedback_v1 *zwp_linux_dmabuf_feedback_v1,
struct wl_array *device)
{
}
static void tranche_done(void *data,
struct zwp_linux_dmabuf_feedback_v1 *zwp_linux_dmabuf_feedback_v1)
{
}
static void tranche_target_device(void *data,
struct zwp_linux_dmabuf_feedback_v1 *zwp_linux_dmabuf_feedback_v1,
struct wl_array *device)
{
}
static void tranche_formats(void *data,
struct zwp_linux_dmabuf_feedback_v1 *zwp_linux_dmabuf_feedback_v1,
struct wl_array *indices)
{
}
static void tranche_flags(void *data,
struct zwp_linux_dmabuf_feedback_v1 *zwp_linux_dmabuf_feedback_v1,
uint32_t flags)
{
}
static const struct zwp_linux_dmabuf_feedback_v1_listener dmabuf_feedback_listener = {
done,
format_table,
main_device,
tranche_done,
tranche_target_device,
tranche_formats,
tranche_flags,
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
};
build: add an additional check for wayland-protocols 1.24 666cb91cf12a4f8b42087530104513b0fc4ba16d added support for v4 of the dmabuf protocol. This was meant to be optional and the fallback support for the old v2 (dates back to 2017[0] well before the 1.15 wayland-protocol version we depend on) was maintained. However, v4 added several new functions and structs that of course aren't defined in old protocol versions so naturally this breaks the build on those systems. Since this is just a niche feature and not really critical to overall wayland support in mpv, just give in and add another check in the build system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf depends on wayland protocols 1-24[1], so go ahead and make that our new check. Fixes #10807. [0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4 [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
2022-10-29 20:07:34 +02:00
#endif
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void registry_handle_add(void *data, struct wl_registry *reg, uint32_t id,
const char *interface, uint32_t ver)
{
int found = 1;
struct vo_wayland_state *wl = data;
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 21:03:34 +02:00
if (!strcmp(interface, wl_compositor_interface.name) && (ver >= 4) && found++) {
wl->compositor = wl_registry_bind(reg, id, &wl_compositor_interface, 4);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->surface = wl_compositor_create_surface(wl->compositor);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
wl->video_surface = wl_compositor_create_surface(wl->compositor);
/* never accept input events on the video surface */
vo_vaapi_wayland/wayland_common: code style fixes A bad person (AKA me) merged this stuff without paying close enough attention to the code style. Reformat this to be in-line with the rest of the wayland code and general mpv style (braces for functions on the next line, horizontally aligning arguments, some cosmetic cleanups for wayland_common.h, etc.).
2022-05-30 19:58:57 +02:00
struct wl_region *region = wl_compositor_create_region(wl->compositor);
wl_surface_set_input_region(wl->video_surface, region);
wl_region_destroy(region);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->cursor_surface = wl_compositor_create_surface(wl->compositor);
wl_surface_add_listener(wl->surface, &surface_listener, wl);
wayland_common: reset the LIVE_RESIZING flag when resizing ends The VO code resets each flag individually, and it doesn't do it for this one. Also make the prints use the struct names rather than the hardcoded ones, forgot to add those to the last wayland_common commit.
2017-10-05 16:34:48 +02:00
}
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
if (!strcmp(interface, wl_subcompositor_interface.name) && (ver >= 1) && found++) {
wl->subcompositor = wl_registry_bind(reg, id, &wl_subcompositor_interface, 1);
}
wayland: bump dmabuf protocol to version 4 Pulled from https://github.com/mpv-player/mpv/pull/10382 The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor containing both formats and modifiers, which makes it possible for the compositor to import the buffers onto planes using explicit modifiers. This is an extremely important efficiency improvement, as the 3D hardware can be left powered off altogether, the vaapi buffer being sent directly from the video hardware to the display controller. It could be possible to support zwp_linux_dmabuf_v1 version 3 as well, but there is no reason beyond compatibility with old stacks. I would recommend to ditch version 2 as well, as modifier-less formats aren’t very useful nowadays.
2022-07-07 12:03:21 +02:00
if (!strcmp (interface, zwp_linux_dmabuf_v1_interface.name) && (ver >= 4) && found++) {
wl->dmabuf = wl_registry_bind(reg, id, &zwp_linux_dmabuf_v1_interface, 4);
build: add an additional check for wayland-protocols 1.24 666cb91cf12a4f8b42087530104513b0fc4ba16d added support for v4 of the dmabuf protocol. This was meant to be optional and the fallback support for the old v2 (dates back to 2017[0] well before the 1.15 wayland-protocol version we depend on) was maintained. However, v4 added several new functions and structs that of course aren't defined in old protocol versions so naturally this breaks the build on those systems. Since this is just a niche feature and not really critical to overall wayland support in mpv, just give in and add another check in the build system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf depends on wayland protocols 1-24[1], so go ahead and make that our new check. Fixes #10807. [0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4 [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
2022-10-29 20:07:34 +02:00
#if HAVE_WAYLAND_PROTOCOLS_1_24
wayland: bump dmabuf protocol to version 4 Pulled from https://github.com/mpv-player/mpv/pull/10382 The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor containing both formats and modifiers, which makes it possible for the compositor to import the buffers onto planes using explicit modifiers. This is an extremely important efficiency improvement, as the 3D hardware can be left powered off altogether, the vaapi buffer being sent directly from the video hardware to the display controller. It could be possible to support zwp_linux_dmabuf_v1 version 3 as well, but there is no reason beyond compatibility with old stacks. I would recommend to ditch version 2 as well, as modifier-less formats aren’t very useful nowadays.
2022-07-07 12:03:21 +02:00
wl->dmabuf_feedback = zwp_linux_dmabuf_v1_get_default_feedback(wl->dmabuf);
zwp_linux_dmabuf_feedback_v1_add_listener(wl->dmabuf_feedback, &dmabuf_feedback_listener, wl);
build: add an additional check for wayland-protocols 1.24 666cb91cf12a4f8b42087530104513b0fc4ba16d added support for v4 of the dmabuf protocol. This was meant to be optional and the fallback support for the old v2 (dates back to 2017[0] well before the 1.15 wayland-protocol version we depend on) was maintained. However, v4 added several new functions and structs that of course aren't defined in old protocol versions so naturally this breaks the build on those systems. Since this is just a niche feature and not really critical to overall wayland support in mpv, just give in and add another check in the build system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf depends on wayland protocols 1-24[1], so go ahead and make that our new check. Fixes #10807. [0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4 [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
2022-10-29 20:07:34 +02:00
#endif
Revert "vo_dmabuf_wayland: drop support for linux-dmabuf-v2" This was originally dropped because it was thought to be unneeded at the time, but at least some devices (rockchip) apparently are still on old compositors that use linux-dmabuf v2. It's not much code, and for testing purposes it's good to have around since it's hard to test drmprime otherwise. Some minor additions are here to support the newly added vaapi-format mapping in v2 of the protocol. This reverts commit a5b9d529eec8d4bb6fc858143337c3573ec8afd0.
2023-02-17 18:24:15 +01:00
} else if (!strcmp (interface, zwp_linux_dmabuf_v1_interface.name) && (ver >= 2) && found++) {
wl->dmabuf = wl_registry_bind(reg, id, &zwp_linux_dmabuf_v1_interface, 2);
zwp_linux_dmabuf_v1_add_listener(wl->dmabuf, &dmabuf_listener, wl);
wl->drm_format_ct_max = 64;
wl->drm_formats = talloc_array(wl, int, wl->drm_format_ct_max);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
}
if (!strcmp (interface, wp_viewporter_interface.name) && (ver >= 1) && found++) {
wl->viewporter = wl_registry_bind (reg, id, &wp_viewporter_interface, 1);
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, wl_data_device_manager_interface.name) && (ver >= 3) && found++) {
wl->dnd_devman = wl_registry_bind(reg, id, &wl_data_device_manager_interface, 3);
wayland_common: require wl_output v2 and send MP_INPUT_RELEASE_ALL on uninit Every compositor (including toy compositors) has had support for wl_output v2 since forever, so there's little point in supporting degraded output for 5 year old releases (especially considering we require zxdg6 which is far more recent).
2017-10-11 20:47:03 +02:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, wl_output_interface.name) && (ver >= 2) && found++) {
struct vo_wayland_output *output = talloc_zero(wl, struct vo_wayland_output);
wayland: fix memory leaks There are still some leaks from wayland-cursor stuff, but there is no way to free the memory as user of the cursor library.
2014-01-08 20:58:32 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
output->wl = wl;
output->id = id;
output->scale = 1;
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
output->name = "";
wayland: disable by default for gnome It turns out that gnome wayland still has very serious issues that make it unusable for playback with mpv. Other compositors mostly behave fine (Plasma is just missing feature but it's not seriously broken), so GNOME gets the special honor of having a warning printed out. The only solution for GNOME users at this time of writing is to either use the Xorg session or use another wayland compositor.
2019-12-30 22:22:02 +01:00
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
ver = MPMIN(ver, 4); /* Cap at 4 in case new events are added later. */
output->output = wl_registry_bind(reg, id, &wl_output_interface, ver);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl_output_add_listener(output->output, &output_listener, output);
wl_list_insert(&wl->output_list, &output->link);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: move subsurfaces to wayland vo Subsurfaces are only used by the wayland vo. Thats why it makes sense to move all osd and subsurface specific parts to the vo_wayland.c Also destroy the subsurfaces and subcompositor properly.
2014-06-15 14:46:27 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, wl_seat_interface.name) && found++) {
wl->seat = wl_registry_bind(reg, id, &wl_seat_interface, 1);
wl_seat_add_listener(wl->seat, &seat_listener, wl);
wayland: add presentation time Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
2019-10-10 21:14:40 +02:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, wl_shm_interface.name) && found++) {
wl->shm = wl_registry_bind(reg, id, &wl_shm_interface, 1);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_27
if (!strcmp(interface, wp_content_type_manager_v1_interface.name) && found++) {
wl->content_type_manager = wl_registry_bind(reg, id, &wp_content_type_manager_v1_interface, 1);
}
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
if (!strcmp(interface, wp_single_pixel_buffer_manager_v1_interface.name) && found++) {
wl->single_pixel_manager = wl_registry_bind(reg, id, &wp_single_pixel_buffer_manager_v1_interface, 1);
}
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
#endif
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_31
if (!strcmp(interface, wp_fractional_scale_manager_v1_interface.name) && found++) {
wl->fractional_scale_manager = wl_registry_bind(reg, id, &wp_fractional_scale_manager_v1_interface, 1);
}
#endif
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, wp_presentation_interface.name) && found++) {
wl->presentation = wl_registry_bind(reg, id, &wp_presentation_interface, 1);
wp_presentation_add_listener(wl->presentation, &pres_listener, wl);
}
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, xdg_wm_base_interface.name) && found++) {
wayland: add support for configure bounds In wayland-protocols 1.25, xdg-shell got a version bump which added the configure_bounds event. The compositor can send this to clients to indicate that they should not resize past a certain size. For mpv, we'll choose to only listen to this on reconfig events (i.e. when the window first appears and if the video resolution changes later in the playlist). However, this behavior is still exposed as a user option (default on) because it will neccesarily conflict with a user setting a specific geometry size and/or window scale. Presumably, if someone is setting a really large size that goes beyond the bounds of their monitor, they actually want it like that. The wayland-protocols version is newer-ish, but we can get around having to poke the build system by just using a define that exists in the generated xdg-shell header.
2022-05-31 15:36:15 +02:00
ver = MPMIN(ver, 4); /* Cap at 4 in case new events are added later. */
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->wm_base = wl_registry_bind(reg, id, &xdg_wm_base_interface, ver);
xdg_wm_base_add_listener(wl->wm_base, &xdg_wm_base_listener, wl);
}
wayland: unify frame/presentation callback code Originally when presentation time was implemented, the frame callback and presentation feedback functions were called in each rendering api's separate backend (egl and vulkan). This meant that their respective structs were basically copy and pasted across both files. Plus later vo_wlshm started using frame callbacks too. Things got refactored a few times and it turns out there's actually no need to have these things separate anymore. The frame callback can just be initialized in vo_wayland_init and then everything else will follow from there. Just move all of this code to wayland_common and get rid of the duplication. Sidenote: This means that vo_wlshm can actually receive presentation feedback now. It's really simple to do so might as well. See the next commit.
2020-12-11 20:14:50 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, zxdg_decoration_manager_v1_interface.name) && found++) {
wl->xdg_decoration_manager = wl_registry_bind(reg, id, &zxdg_decoration_manager_v1_interface, 1);
}
wayland: fix memory leaks There are still some leaks from wayland-cursor stuff, but there is no way to free the memory as user of the cursor library.
2014-01-08 20:58:32 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!strcmp(interface, zwp_idle_inhibit_manager_v1_interface.name) && found++) {
wl->idle_inhibit_manager = wl_registry_bind(reg, id, &zwp_idle_inhibit_manager_v1_interface, 1);
}
if (found > 1)
MP_VERBOSE(wl, "Registered for protocol %s\n", interface);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void registry_handle_remove(void *data, struct wl_registry *reg, uint32_t id)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_wayland_state *wl = data;
struct vo_wayland_output *output, *tmp;
wl_list_for_each_safe(output, tmp, &wl->output_list, link) {
if (output->id == id) {
remove_output(output);
return;
}
}
}
wayland/shm: Use subsurfaces for OSD
2014-01-28 13:07:00 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const struct wl_registry_listener registry_listener = {
registry_handle_add,
registry_handle_remove,
};
wayland_common: require wl_output v2 and send MP_INPUT_RELEASE_ALL on uninit Every compositor (including toy compositors) has had support for wl_output v2 since forever, so there's little point in supporting degraded output for 5 year old releases (especially considering we require zxdg6 which is far more recent).
2017-10-11 20:47:03 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
/* Static functions */
static void check_dnd_fd(struct vo_wayland_state *wl)
{
if (wl->dnd_fd == -1)
return;
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct pollfd fdp = { wl->dnd_fd, POLLIN | POLLERR | POLLHUP, 0 };
if (poll(&fdp, 1, 0) <= 0)
return;
wayland: dynamically report display fps Only reports the most recently entered output if the window is displayed on 2 or more outputs. Should be changed to the lowest fps of all outputs the window is visible. Until no one complains this will have to wait. Look for the VO framedropping for more information on this topic.
2014-08-18 22:00:39 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (fdp.revents & POLLIN) {
ptrdiff_t offset = 0;
size_t data_read = 0;
const size_t chunk_size = 1;
uint8_t *buffer = ta_zalloc_size(wl, chunk_size);
if (!buffer)
goto end;
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
while ((data_read = read(wl->dnd_fd, buffer + offset, chunk_size)) > 0) {
offset += data_read;
buffer = ta_realloc_size(wl, buffer, offset + chunk_size);
memset(buffer + offset, 0, chunk_size);
if (!buffer)
goto end;
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
MP_VERBOSE(wl, "Read %td bytes from the DND fd\n", offset);
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct bstr file_list = bstr0(buffer);
mp_event_drop_mime_data(wl->vo->input_ctx, wl->dnd_mime_type,
file_list, wl->dnd_action);
talloc_free(buffer);
end:
wayland: partially fix drag and drop handling Drag and drop in wayland is weird and it seems everyone does this slightly differently (fun). In the past, there was a crash that occured (fixed by 700f4ef5fad353800fa866b059663bc1dd58d3b7) which involved using the wl_data_offer_finish in an incorrect way that triggered a protocol error (always fatal). The fix involved moving the function call to data_device_handle_drop which seemingly works, but it has an unfortunate side effect. It appears like GTK applications (or at least firefox) close the pipe after this function is called which makes it impossible for mpv to read data from the fd (well you could force it open again in theory but let's not do that). Who knows if that was the case when that commit was made (probably not because I'd think I would have noticed; could just be a dummy though), but obviously having broken dnd for a major application isn't so fun (this works with QT and chromium anyway). Ideally one would just simply check the pipe in data_device_handle_drop, but this doesn't work because it doesn't seem the compositor actually sends mpv the data by then. There's not actually a defined event when you're supposed to be able to read data from this pipe, so we wait for the usual event checking loop later for this. In that case, wl_data_offer_finish needs to go back into check_dnd_fd, but we have to be careful when calling it otherwise we'd just commit protocol errors like before. We check to make sure we even have a valid wl->dnd_offer before trying to indicate that it is finished and additionally make sure there is a valid dnd_action (after checking the fd, it's always set back to -1). This doesn't fix everything though. Specifically, sway with focus_follows_mouse (the default) and GTK as the data source still doesn't work. The reason is that when you do a drag and drop in sway with that option on, a new wl_data_device.data_offer event is sent out instantly after the drop event. This happens before any data is sent across the fd and before mpv even has a chance to check it. What GTK does, when getting this new data_offer event, is close the pipe (POLLHUP). This means mpv can't read it when we reach the event loop and thus no data is ever read and broken drag and drop. From the client side, this isn't really fixable since the wayland protocol doesn't have a clear indication of when clients are supposed to read from the fd and both the compositor and data source are doing things totally out of our control. So we'll consider this weird case, "not our bug" at least. The rest should work.
2022-02-03 17:48:56 +01:00
if (wl->dnd_mime_type)
talloc_free(wl->dnd_mime_type);
if (wl->dnd_action >= 0 && wl->dnd_offer)
wl_data_offer_finish(wl->dnd_offer);
wl->dnd_action = -1;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->dnd_mime_type = NULL;
wl->dnd_mime_score = 0;
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (fdp.revents & (POLLIN | POLLERR | POLLHUP)) {
close(wl->dnd_fd);
wl->dnd_fd = -1;
}
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static int check_for_resize(struct vo_wayland_state *wl, wl_fixed_t x_w, wl_fixed_t y_w,
int edge_pixels, enum xdg_toplevel_resize_edge *edge)
{
wayland: improve behavior with touch events There's currently some touch related code in mpv wayland, but clearly nobody actually uses because it's a broken mess. Initially an attempt to distinguish between two finger touches and one finger touch was made, but there's not a good way to make this work. For whatever reason, initiating either xdg_toplevel_resize or xdg_toplevel_move blocks any other touch events from occurring (at least in plasma). Trying to call these functions anywhere else is not really useful since the serial will be invalid outside of the touch down events (well it would work in the touch up event but that's just silly). Anyways, let's just make this work sanely. Eliminate the touch entries variable completely because it's pointless. Only one finger event is ever considered at a time. Touches besides the initial one are all ignored. If a user touches and drags within the touch edge radius, then a resize event occurs. If the user touches and drags elsewhere on the window, a move event occurs. A single tap displays the osc (which is clickable if you tap again). A double tap toggles fullscreen. Additionally, the default touch edge radius of 64 pixels is way too big (at least I think so). Cut this in half to 32 which feels a lot better (on a pinephone using plasma mobile anyway).
2021-08-08 05:05:05 +02:00
if (wl->vo_opts->fullscreen || wl->vo_opts->window_maximized)
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return 0;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
int pos[2] = { wl_fixed_to_double(x_w), wl_fixed_to_double(y_w) };
int left_edge = pos[0] < edge_pixels;
int top_edge = pos[1] < edge_pixels;
int right_edge = pos[0] > (mp_rect_w(wl->geometry) - edge_pixels);
int bottom_edge = pos[1] > (mp_rect_h(wl->geometry) - edge_pixels);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (left_edge) {
*edge = XDG_TOPLEVEL_RESIZE_EDGE_LEFT;
if (top_edge)
*edge = XDG_TOPLEVEL_RESIZE_EDGE_TOP_LEFT;
else if (bottom_edge)
*edge = XDG_TOPLEVEL_RESIZE_EDGE_BOTTOM_LEFT;
} else if (right_edge) {
*edge = XDG_TOPLEVEL_RESIZE_EDGE_RIGHT;
if (top_edge)
*edge = XDG_TOPLEVEL_RESIZE_EDGE_TOP_RIGHT;
else if (bottom_edge)
*edge = XDG_TOPLEVEL_RESIZE_EDGE_BOTTOM_RIGHT;
} else if (top_edge) {
*edge = XDG_TOPLEVEL_RESIZE_EDGE_TOP;
} else if (bottom_edge) {
*edge = XDG_TOPLEVEL_RESIZE_EDGE_BOTTOM;
} else {
*edge = 0;
return 0;
}
wayland: fix memory leaks There are still some leaks from wayland-cursor stuff, but there is no way to free the memory as user of the cursor library.
2014-01-08 20:58:32 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return 1;
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static bool create_input(struct vo_wayland_state *wl)
{
wl->xkb_context = xkb_context_new(XKB_CONTEXT_NO_FLAGS);
vo_wayland: share frame callbacks. Define frame callback logic in wayland_common.c As this should be used by opengl renderer as well. Preferably drawing should be skipped entierly when no frame callbacks are received. However, for now only swap buffers is skipped.
2015-03-22 01:47:27 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!wl->xkb_context) {
MP_ERR(wl, "failed to initialize input: check xkbcommon\n");
return 1;
}
wayland: fix wl_proxy leak This one is probably not terribly obvious from just the valgrind log, but a wayland dev explained it to me just a second ago. Whenever mpv sends events to the screen with wl_display_dispatch, wayland internally allocates memory to a struct wl_proxy object if a new id is found. Quite a few more things happen to that proxy object, but eventually mpv stores the data on the client-side in a wrapper type of struct (struct wl_data_offer). mpv's data_device_listener keeps track of those proxies and frees the memory when appropriate. Of course, mpv is constantly sending events to the screen and does so until the user quits the player. What happens here is that one final wl_display_dispatch is called right before the user quits the player and before mpv's data_device_listener can handle that object. So the result is that you always have one extra dangling proxy that doesn't get properly freed. The solution is to just simply call wl_data_offer_destroy before closing the wl_display to free that final dangling wl_proxy.
2019-08-07 16:26:24 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return 0;
}
wayland: use xdg-decoration if available
2018-11-07 13:53:46 +01:00
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
static int create_viewports(struct vo_wayland_state *wl)
{
if (wl->viewporter) {
wl->viewport = wp_viewporter_get_viewport(wl->viewporter, wl->surface);
wl->video_viewport = wp_viewporter_get_viewport(wl->viewporter, wl->video_surface);
}
if (wl->viewporter && (!wl->viewport || !wl->video_viewport)) {
MP_ERR(wl, "failed to create viewport interfaces!\n");
return 1;
}
return 0;
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static int create_xdg_surface(struct vo_wayland_state *wl)
{
wl->xdg_surface = xdg_wm_base_get_xdg_surface(wl->wm_base, wl->surface);
xdg_surface_add_listener(wl->xdg_surface, &xdg_surface_listener, wl);
wayland: use xdg-decoration if available
2018-11-07 13:53:46 +01:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->xdg_toplevel = xdg_surface_get_toplevel(wl->xdg_surface);
xdg_toplevel_add_listener(wl->xdg_toplevel, &xdg_toplevel_listener, wl);
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
if (!wl->xdg_surface || !wl->xdg_toplevel) {
MP_ERR(wl, "failled to create xdg_surface and xdg_toplevel!\n");
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return 1;
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return 0;
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
static void add_feedback(struct vo_wayland_feedback_pool *fback_pool,
struct wp_presentation_feedback *fback)
{
for (int i = 0; i < fback_pool->len; ++i) {
if (!fback_pool->fback[i]) {
fback_pool->fback[i] = fback;
break;
} else if (i == fback_pool->len - 1) {
// Shouldn't happen in practice.
wp_presentation_feedback_destroy(fback_pool->fback[i]);
fback_pool->fback[i] = fback;
}
}
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void do_minimize(struct vo_wayland_state *wl)
{
if (!wl->xdg_toplevel)
return;
if (wl->vo_opts->window_minimized)
xdg_toplevel_set_minimized(wl->xdg_toplevel);
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static char **get_displays_spanned(struct vo_wayland_state *wl)
{
char **names = NULL;
int displays_spanned = 0;
struct vo_wayland_output *output;
wl_list_for_each(output, &wl->output_list, link) {
wayland: use wl_output v4 for display-names 5774ce759a6c7fe0727cfbd4458957abfd96a7b7 added the new output name event and used them for the --fs-screen-name option. It turns out that the display-names property could also make use of these names, so go ahead and use output->name in this case if we have them. If not, fallback to output->model like before.
2022-05-13 20:48:46 +02:00
if (output->has_surface) {
char *name = output->name ? output->name : output->model;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
MP_TARRAY_APPEND(NULL, names, displays_spanned,
wayland: use wl_output v4 for display-names 5774ce759a6c7fe0727cfbd4458957abfd96a7b7 added the new output name event and used them for the --fs-screen-name option. It turns out that the display-names property could also make use of these names, so go ahead and use output->name in this case if we have them. If not, fallback to output->model like before.
2022-05-13 20:48:46 +02:00
talloc_strdup(NULL, name));
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
MP_TARRAY_APPEND(NULL, names, displays_spanned, NULL);
return names;
}
wayland: changes for nested compositors Adds necessary checks for nested compositors which only have limited interfaces. Might also be useful for other minimal compositors.
2014-08-06 12:41:33 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static int get_mods(struct vo_wayland_state *wl)
{
static char* const mod_names[] = {
XKB_MOD_NAME_SHIFT,
XKB_MOD_NAME_CTRL,
XKB_MOD_NAME_ALT,
XKB_MOD_NAME_LOGO,
};
wayland: pointer interface is created after theme Just always load the theme. It gets freed properly and dosn't bother anyone. Fixes #1012. CC: @mpv-player/stable
2014-08-13 22:32:22 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static const int mods[] = {
MP_KEY_MODIFIER_SHIFT,
MP_KEY_MODIFIER_CTRL,
MP_KEY_MODIFIER_ALT,
MP_KEY_MODIFIER_META,
};
wayland: add presentation time Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
2019-10-10 21:14:40 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
int modifiers = 0;
wayland: destroy presentation feedback on uninit Nothing major but it's technically possible for the wp_presentation_feedback struct to still be allocated when quitting the player. Just destroy it if it exists like all of the other wayland objects.
2020-08-15 01:22:58 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
for (int n = 0; n < MP_ARRAY_SIZE(mods); n++) {
xkb_mod_index_t index = xkb_keymap_mod_get_index(wl->xkb_keymap, mod_names[n]);
if (!xkb_state_mod_index_is_consumed(wl->xkb_state, wl->keyboard_code, index)
&& xkb_state_mod_index_is_active(wl->xkb_state, index,
XKB_STATE_MODS_DEPRESSED))
modifiers |= mods[n];
}
return modifiers;
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void greatest_common_divisor(struct vo_wayland_state *wl, int a, int b) {
// euclidean algorithm
int larger;
int smaller;
if (a > b) {
larger = a;
smaller = b;
} else {
larger = b;
smaller = a;
}
int remainder = larger - smaller * floor(larger/smaller);
if (remainder == 0) {
wl->gcd = smaller;
} else {
greatest_common_divisor(wl, smaller, remainder);
}
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static struct vo_wayland_output *find_output(struct vo_wayland_state *wl)
{
int index = 0;
int screen_id = wl->vo_opts->fsscreen_id;
char *screen_name = wl->vo_opts->fsscreen_name;
struct vo_wayland_output *output = NULL;
struct vo_wayland_output *fallback_output = NULL;
wl_list_for_each(output, &wl->output_list, link) {
if (index == 0)
fallback_output = output;
if (screen_id == -1 && !screen_name)
return output;
wayland: use wl_output v4 for --fs-screen-name In wayland 1.20.0, a couple of new events, name and description, were added to the interface. Description is not particularly useful, but name returns back nice names for the output like "DP-1" and so on. It makes sense to use these for fs-screen-name and prefer them over the model name (old way of doing it) if they are available. The only problem is that 1.20.0 is pretty new so old distros aren't going to have it anytime soon. Deal with this by adding some defines.
2022-04-08 17:19:39 +02:00
if (screen_id == -1 && screen_name && !strcmp(screen_name, output->name))
return output;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (screen_id == -1 && screen_name && !strcmp(screen_name, output->model))
return output;
if (screen_id == index++)
return output;
}
if (!fallback_output) {
MP_ERR(wl, "No screens could be found!\n");
return NULL;
} else if (wl->vo_opts->fsscreen_id >= 0) {
MP_WARN(wl, "Screen index %i not found/unavailable! Falling back to screen 0!\n", screen_id);
} else if (wl->vo_opts->fsscreen_name) {
MP_WARN(wl, "Screen name %s not found/unavailable! Falling back to screen 0!\n", screen_name);
}
return fallback_output;
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static int lookupkey(int key)
{
const char *passthrough_keys = " -+*/<>`~!@#$%^&()_{}:;\"\',.?\\|=[]";
int mpkey = 0;
if ((key >= 'a' && key <= 'z') || (key >= 'A' && key <= 'Z') ||
(key >= '0' && key <= '9') ||
(key > 0 && key < 256 && strchr(passthrough_keys, key)))
mpkey = key;
if (!mpkey)
mpkey = lookup_keymap_table(keymap, key);
return mpkey;
}
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
static void request_decoration_mode(struct vo_wayland_state *wl, uint32_t mode)
{
wl->requested_decoration = mode;
zxdg_toplevel_decoration_v1_set_mode(wl->xdg_toplevel_decoration, mode);
}
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
static void rescale_geometry(struct vo_wayland_state *wl, double old_scale)
{
double factor = old_scale / wl->scaling;
wl->window_size.x1 /= factor;
wl->window_size.y1 /= factor;
wl->geometry.x1 /= factor;
wl->geometry.y1 /= factor;
}
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
static void clean_feedback_pool(struct vo_wayland_feedback_pool *fback_pool)
{
for (int i = 0; i < fback_pool->len; ++i) {
if (fback_pool->fback[i]) {
wp_presentation_feedback_destroy(fback_pool->fback[i]);
fback_pool->fback[i] = NULL;
}
}
}
static void remove_feedback(struct vo_wayland_feedback_pool *fback_pool,
struct wp_presentation_feedback *fback)
{
for (int i = 0; i < fback_pool->len; ++i) {
if (fback_pool->fback[i] == fback) {
wp_presentation_feedback_destroy(fback);
fback_pool->fback[i] = NULL;
break;
}
}
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void remove_output(struct vo_wayland_output *out)
{
if (!out)
return;
MP_VERBOSE(out->wl, "Deregistering output %s %s (0x%x)\n", out->make,
out->model, out->id);
wl_list_remove(&out->link);
talloc_free(out->make);
talloc_free(out->model);
talloc_free(out);
return;
}
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
static void set_content_type(struct vo_wayland_state *wl)
{
if (!wl->content_type_manager)
return;
#if HAVE_WAYLAND_PROTOCOLS_1_27
// handle auto;
if (wl->vo_opts->content_type == -1) {
wp_content_type_v1_set_content_type(wl->content_type, wl->current_content_type);
} else {
wp_content_type_v1_set_content_type(wl->content_type, wl->vo_opts->content_type);
}
#endif
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static int set_cursor_visibility(struct vo_wayland_state *wl, bool on)
{
wl->cursor_visible = on;
if (on) {
if (spawn_cursor(wl))
return VO_FALSE;
struct wl_cursor_image *img = wl->default_cursor->images[0];
struct wl_buffer *buffer = wl_cursor_image_get_buffer(img);
if (!buffer)
return VO_FALSE;
wl_pointer_set_cursor(wl->pointer, wl->pointer_id, wl->cursor_surface,
img->hotspot_x/wl->scaling, img->hotspot_y/wl->scaling);
wl_surface_set_buffer_scale(wl->cursor_surface, wl->scaling);
wl_surface_attach(wl->cursor_surface, buffer, 0, 0);
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 21:03:34 +02:00
wl_surface_damage_buffer(wl->cursor_surface, 0, 0, img->width, img->height);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl_surface_commit(wl->cursor_surface);
} else {
wl_pointer_set_cursor(wl->pointer, wl->pointer_id, NULL, 0, 0);
}
return VO_TRUE;
}
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
static void set_geometry(struct vo_wayland_state *wl, bool resize)
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
{
struct vo *vo = wl->vo;
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
if (!wl->current_output)
return;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_win_geometry geo;
struct mp_rect screenrc = wl->current_output->geometry;
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
vo_calc_window_geometry2(vo, &screenrc, wl->scaling, &geo);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
vo_apply_window_geometry(vo, &geo);
greatest_common_divisor(wl, vo->dwidth, vo->dheight);
wl->reduced_width = vo->dwidth / wl->gcd;
wl->reduced_height = vo->dheight / wl->gcd;
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
wl->window_size = (struct mp_rect){0, 0, vo->dwidth, vo->dheight};
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
if (resize) {
if (!wl->vo_opts->fullscreen && !wl->vo_opts->window_maximized)
wl->geometry = wl->window_size;
wl->pending_vo_events |= VO_EVENT_RESIZE;
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
static int set_screensaver_inhibitor(struct vo_wayland_state *wl, int state)
{
if (!wl->idle_inhibit_manager)
return VO_NOTIMPL;
if (state == (!!wl->idle_inhibitor))
return VO_TRUE;
if (state) {
MP_VERBOSE(wl, "Enabling idle inhibitor\n");
struct zwp_idle_inhibit_manager_v1 *mgr = wl->idle_inhibit_manager;
wl->idle_inhibitor = zwp_idle_inhibit_manager_v1_create_inhibitor(mgr, wl->surface);
} else {
MP_VERBOSE(wl, "Disabling the idle inhibitor\n");
zwp_idle_inhibitor_v1_destroy(wl->idle_inhibitor);
wl->idle_inhibitor = NULL;
}
return VO_TRUE;
}
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
static void set_surface_scaling(struct vo_wayland_state *wl)
{
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
if (wl->fractional_scale_manager)
return;
// dmabuf_wayland is always wl->scaling = 1
vo_vaapi_wayland: remove, as it is superceded by vo_dmabuf_wayland
2022-09-29 15:50:51 +02:00
bool dmabuf_wayland = !strcmp(wl->vo->driver->name, "dmabuf-wayland");
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
double old_scale = wl->scaling;
wayland: handle runtime hidpi-window-scale changes correctly Semi-regression although this option never really did what the manual said until recently. In the past, this option also controlled whether or not mpv set the wayland buffer_scale to the value of the wl_output or force it 1. This had varying effects depending on the exact compositor configuration. That logic has now all been removed and this option now only controls whether or not to scale the window with the hidpi scale factor we get from the compositor. i.e. it actually does what the manual says now.
2023-01-26 20:17:39 +01:00
wl->scaling = !dmabuf_wayland ? wl->current_output->scale : 1;
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
rescale_geometry(wl, old_scale);
wayland: remove bogus scale_change variable This was originally added in f2afae55e95b4b1eec1aeb828ba6ff1f0695d993 for unclear reasons (way to go me). This concept is clearly incorrect. It doesn't matter what state the window is in. As soon as mpv detects a scale change, it needs to reset the buffer scale of the window. Just remove all this junk and put wl_surface_set_buffer_scale in set_surface_scaling like it should be. Related issue: #9426.
2021-11-08 16:44:22 +01:00
wl_surface_set_buffer_scale(wl->surface, wl->scaling);
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
}
wayland: add support for configure bounds In wayland-protocols 1.25, xdg-shell got a version bump which added the configure_bounds event. The compositor can send this to clients to indicate that they should not resize past a certain size. For mpv, we'll choose to only listen to this on reconfig events (i.e. when the window first appears and if the video resolution changes later in the playlist). However, this behavior is still exposed as a user option (default on) because it will neccesarily conflict with a user setting a specific geometry size and/or window scale. Presumably, if someone is setting a really large size that goes beyond the bounds of their monitor, they actually want it like that. The wayland-protocols version is newer-ish, but we can get around having to poke the build system by just using a define that exists in the generated xdg-shell header.
2022-05-31 15:36:15 +02:00
static void set_window_bounds(struct vo_wayland_state *wl)
{
wayland: add auto choice to wayland-configure-bounds Previously, this defaulted to yes and configure-bounds from the compositor would always apply. In the case where the user explicitly set autofit or geometry, this could be confusing because configure-bounds would take precedence over it. Instead, let's add an auto choice and make that the default. If we detect that the option is on auto and that there is autofit/geometry being set, then ignore the event. This should be more intuitive since someone who bothers to explicitly set mpv's geometry would naturally expect that geometry to actually apply.
2023-01-26 21:21:58 +01:00
// If the user has set geometry/autofit and the option is auto,
// don't use these.
if (wl->opts->configure_bounds == -1 && (wl->vo_opts->geometry.wh_valid ||
wl->vo_opts->autofit.wh_valid || wl->vo_opts->autofit_larger.wh_valid ||
wl->vo_opts->autofit_smaller.wh_valid))
{
return;
}
wayland: add support for configure bounds In wayland-protocols 1.25, xdg-shell got a version bump which added the configure_bounds event. The compositor can send this to clients to indicate that they should not resize past a certain size. For mpv, we'll choose to only listen to this on reconfig events (i.e. when the window first appears and if the video resolution changes later in the playlist). However, this behavior is still exposed as a user option (default on) because it will neccesarily conflict with a user setting a specific geometry size and/or window scale. Presumably, if someone is setting a really large size that goes beyond the bounds of their monitor, they actually want it like that. The wayland-protocols version is newer-ish, but we can get around having to poke the build system by just using a define that exists in the generated xdg-shell header.
2022-05-31 15:36:15 +02:00
if (wl->bounded_width && wl->bounded_width < wl->window_size.x1)
wl->window_size.x1 = wl->bounded_width;
if (wl->bounded_height && wl->bounded_height < wl->window_size.y1)
wl->window_size.y1 = wl->bounded_height;
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static int spawn_cursor(struct vo_wayland_state *wl)
{
/* Reuse if size is identical */
if (!wl->pointer || wl->allocated_cursor_scale == wl->scaling)
return 0;
else if (wl->cursor_theme)
wl_cursor_theme_destroy(wl->cursor_theme);
wayland: read XCURSOR_THEME to get cursor theme Read $XCURSOR_THEME environment variable if set and if not then fall back to "default" (/usr/share/icons/default and ~/.icons/default)
2021-08-28 01:04:14 +02:00
const char *xcursor_theme = getenv("XCURSOR_THEME");
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
const char *size_str = getenv("XCURSOR_SIZE");
wayland: set default cursor size to 24 Set it to 24 if it couldn't be read frome $XCURSOR_SIZE for some reason. Since it seems to be the default value for most distros/DE.
2021-08-28 01:11:50 +02:00
int size = 24;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (size_str != NULL) {
errno = 0;
char *end;
long size_long = strtol(size_str, &end, 10);
if (!*end && !errno && size_long > 0 && size_long <= INT_MAX)
size = (int)size_long;
}
wayland: fix various memory leaks
2019-05-13 15:47:13 +02:00
wayland: read XCURSOR_THEME to get cursor theme Read $XCURSOR_THEME environment variable if set and if not then fall back to "default" (/usr/share/icons/default and ~/.icons/default)
2021-08-28 01:04:14 +02:00
wl->cursor_theme = wl_cursor_theme_load(xcursor_theme, size*wl->scaling, wl->shm);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!wl->cursor_theme) {
MP_ERR(wl, "Unable to load cursor theme!\n");
return 1;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: separate shm and cursor context The display, window, keyboard and cursor structures are now cleanly and logically separated. Also could prevent a future bug where no shm format is set when the cursor image is loaded (Never happened until now).
2013-08-19 14:07:17 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->default_cursor = wl_cursor_theme_get_cursor(wl->cursor_theme, "left_ptr");
if (!wl->default_cursor) {
MP_ERR(wl, "Unable to load cursor theme!\n");
return 1;
}
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->allocated_cursor_scale = wl->scaling;
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return 0;
wayland: use a unified struct for the state This commit removes the pointer to the single different structures for input and window and puts them as anonymous structures inside the wayland_state structure. This has the disadvantage of passing the substructure to the listeners, but the advantage is that we don't have to allocate them and check for NULL pointers. This makes it more reliable and easier to follow.
2013-07-18 17:35:28 +02:00
}
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
static void toggle_fullscreen(struct vo_wayland_state *wl)
{
if (!wl->xdg_toplevel)
return;
wl->state_change = true;
wayland: support fs-screen-name option In wayland, setting the surface on a specific monitor only works in fullscreen so only --fs-screen-name can be implemented. Like with x11, we prefer --fs-screen over --fs-screen-name if it is set. This may be more useful than setting by ids because there's no guaranteed order in which screens are added in wayland. In wayland, the name used here is the model name detected by the output_listener.
2020-11-23 21:56:24 +01:00
bool specific_screen = wl->vo_opts->fsscreen_id >= 0 || wl->vo_opts->fsscreen_name;
if (wl->vo_opts->fullscreen && !specific_screen) {
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
xdg_toplevel_set_fullscreen(wl->xdg_toplevel, NULL);
wayland: support fs-screen-name option In wayland, setting the surface on a specific monitor only works in fullscreen so only --fs-screen-name can be implemented. Like with x11, we prefer --fs-screen over --fs-screen-name if it is set. This may be more useful than setting by ids because there's no guaranteed order in which screens are added in wayland. In wayland, the name used here is the model name detected by the output_listener.
2020-11-23 21:56:24 +01:00
} else if (wl->vo_opts->fullscreen && specific_screen) {
wayland: handle multiple outputs more correctly There's a bit of a catch-22 in the wayland backend. mpv needs to know several things about the wl_output the surface is on (geometry, scale, etc.) for lots of its options. You still have to render something somewhere before you can know what wl_output the surface is actually on. So this means that when initializing the player, it is entirely possible to calculate initial parameters using the wrong wl_output. The surface listener is what will eventually correct this and pick the correct output. However not everything was technically working correctly in a multi-output setup. The first rule here is to rework find_output so that it returns a vo_wayland_output instead of internally setting wl->current_output. The reason is simply because the output found here is not guaranteed to be the output the surface is actually on. Note that for initialization of the player, we must set the output returned from this function as the wl->current_output even if it is not technically correct. The surface listener will fix it later. vo_wayland_reconfig has to confusingly serve two roles. It must ensure some wayland-related things are configured as well as setup things for mpv's vo. The various functions are shuffled around and some things are removed here which has subtle implications. For instance, there's no reason to always set the buffer scale. It only needs to be done once (when the wl->current_output is being created). A roundtrip needs to be done once after a wl_surface_commit to ensure there are no configuration errors. surface_handle_enter is now handles two different things: scaling as well as mpv's autofit/geometry options. When a surface enters a new output, the new scaling value is applied to all of the geometry-related structs (previously, this wasn't done). This ensures, in a multi-monitor case with mixed scale values, the surface is rescaled correctly to the actual output it is on if the initial selection of wl->current_output is incorrect. Additionally, autofit/geometry values are recalculated if they exist. This means that dragging a surface across different outputs will autofit correctly to the new output and not always be "stuck" on the old one. A very astute observer may notice that set_buffer_scale isn't set when the surface enters a new output. The API doesn't really indicate this, but a WAYLAND_DEBUG log reveals that the compositor (well at least sway/wlroots anyway) magically sets this for you. That's quite fortunate because setting in the surface handler caused all sorts of problems.
2020-12-07 00:34:36 +01:00
struct vo_wayland_output *output = find_output(wl);
xdg_toplevel_set_fullscreen(wl->xdg_toplevel, output->output);
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
} else {
xdg_toplevel_unset_fullscreen(wl->xdg_toplevel);
}
}
static void toggle_maximized(struct vo_wayland_state *wl)
{
if (!wl->xdg_toplevel)
return;
wl->state_change = true;
if (wl->vo_opts->window_maximized) {
xdg_toplevel_set_maximized(wl->xdg_toplevel);
} else {
xdg_toplevel_unset_maximized(wl->xdg_toplevel);
}
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void update_app_id(struct vo_wayland_state *wl)
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
{
if (!wl->xdg_toplevel)
return;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
xdg_toplevel_set_app_id(wl->xdg_toplevel, wl->vo_opts->appid);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland: allow vo_wayland_uninit(NULL)
2017-09-16 06:24:57 +02:00
wayland: tweak xdg_surface creation Just some small changes when creating the xdg_surface. Don't set the toplevel title (or app id) in create_xdg_surface anymore because it's entirely pointless. Also make it possible for create_xdg_surface to return something other than 0 so the error checking is somewhat meaningful. It's not really clear if these xdg functions can even fail in the first place (perhaps some weird proxy marshalling crap could possibly go wrong somehow), but it can't hurt. Note that all app id stuff has been removed (temporarily) in this commit. See the next commit which adds it back in.
2020-08-12 16:41:56 +02:00
static int update_window_title(struct vo_wayland_state *wl, const char *title)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
if (!wl->xdg_toplevel)
return VO_NOTAVAIL;
wayland: sanitize toplevel title to UTF-8 The xdg-shell protocol requires that the toplevel title is UTF-8*. Go ahead and leverage existing mpv tools to sanitize the title. Fixes #9694 *: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/0aaf12157ede8fdf6eda49963da313bd1a7d930f/stable/xdg-shell/xdg-shell.xml#L638
2022-01-19 02:45:27 +01:00
/* The xdg-shell protocol requires that the title is UTF-8. */
void *tmp = talloc_new(NULL);
struct bstr b_title = bstr_sanitize_utf8_latin1(tmp, bstr0(title));
wayland, x11: fix possibly unsafe bstr usage In practice this never led to any issues due to implementation details of bstr_sanitize_utf8_latin1, but there's no guarantee that a bstr is correctly null-terminated.
2022-11-09 15:03:18 +01:00
xdg_toplevel_set_title(wl->xdg_toplevel, bstrto0(tmp, b_title));
wayland: sanitize toplevel title to UTF-8 The xdg-shell protocol requires that the toplevel title is UTF-8*. Go ahead and leverage existing mpv tools to sanitize the title. Fixes #9694 *: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/0aaf12157ede8fdf6eda49963da313bd1a7d930f/stable/xdg-shell/xdg-shell.xml#L638
2022-01-19 02:45:27 +01:00
talloc_free(tmp);
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
return VO_TRUE;
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
static void window_move(struct vo_wayland_state *wl, uint32_t serial)
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->xdg_toplevel)
xdg_toplevel_move(wl->xdg_toplevel, wl->seat, serial);
}
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
wayland: dispatch and wait for compositor events in uninit Similar to some other issues we've had with unprocessed compositor events. When quitting mpv, there's two things we should be doing: dispatching any last minute wayland events and then waiting for a compositor reply. Luckily, there's already an internal helper for this (renamed to wayland_dispatch_events for consistency) that we can use. All of the special casing of wl->feedback becomes unneccesary and we can remove this from vo_wayland_state with this method. Fixes #110022.
2023-01-01 03:51:13 +01:00
static void wayland_dispatch_events(struct vo_wayland_state *wl, int nfds, int timeout)
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
{
wayland: initalize display_fd as -1 In the event of a failed wayland initalization, the display_fd is actually 0 instead of -1 which would correctly indicate it doesn't exist. Also move the fd check inside vo_wayland_dispatch_events since that function shouldn't ever do anything if we don't actually have a display fd.
2023-01-01 18:16:31 +01:00
if (wl->display_fd == -1)
return;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct pollfd fds[2] = {
{.fd = wl->display_fd, .events = POLLIN },
{.fd = wl->wakeup_pipe[0], .events = POLLIN },
};
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
while (wl_display_prepare_read(wl->display) != 0)
wl_display_dispatch_pending(wl->display);
wl_display_flush(wl->display);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
poll(fds, nfds, timeout);
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wayland: cancel prepared reads when no events A read can be prepared on the wayland display FD that is never actually read. This occurs when events are triggered on other FDs in the fd set. This change cancels a prepared read if poll reported no events for it. This fixes some hangs due to how nvidia's EGL implementation polls on the wayland fd unlike mesa implementations. It is based on nvidia's proposed fix for qt's similar message pump in https://codereview.qt-project.org/c/qt/qtwayland/+/373473 Signed-off-by: Kurt Kartaltepe <kkartaltepe@gmail.com>
2021-11-25 01:40:31 +01:00
if (fds[0].revents & POLLIN) {
wl_display_read_events(wl->display);
} else {
wl_display_cancel_read(wl->display);
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (fds[0].revents & (POLLERR | POLLHUP | POLLNVAL)) {
MP_FATAL(wl, "Error occurred on the display fd, closing\n");
close(wl->display_fd);
wl->display_fd = -1;
mp_input_put_key(wl->vo->input_ctx, MP_KEY_CLOSE_WIN);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (fds[1].revents & POLLIN)
mp_flush_wakeup_pipe(wl->wakeup_pipe[0]);
wayland: cancel prepared reads when no events A read can be prepared on the wayland display FD that is never actually read. This occurs when events are triggered on other FDs in the fd set. This change cancels a prepared read if poll reported no events for it. This fixes some hangs due to how nvidia's EGL implementation polls on the wayland fd unlike mesa implementations. It is based on nvidia's proposed fix for qt's similar message pump in https://codereview.qt-project.org/c/qt/qtwayland/+/373473 Signed-off-by: Kurt Kartaltepe <kkartaltepe@gmail.com>
2021-11-25 01:40:31 +01:00
wl_display_dispatch_pending(wl->display);
wayland: add wayland support All wayland only specific routines are placed in wayland_common. This makes it easier to write other video outputs. The EGL specific parts, as well as opengl context creation, are in gl_common. This backend works for: * opengl-old * opengl * opengl-hq To use it just specify the opengl backend --vo=opengl:backend=wayland or disable the x11 build. Don't forget to set EGL_PLATFORM to wayland. Co-Author: Scott Moreau (Sorry I lost the old commit history due to the file structure changes)
2013-02-28 19:55:02 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
/* Non-static */
vo: move allocate_memfd method to wayland_common
2022-05-30 19:19:23 +02:00
int vo_wayland_allocate_memfd(struct vo *vo, size_t size)
{
#if !HAVE_MEMFD_CREATE
return VO_ERROR;
#else
int fd = memfd_create("mpv", MFD_CLOEXEC | MFD_ALLOW_SEALING);
if (fd < 0) {
MP_ERR(vo, "Failed to allocate memfd: %s\n", mp_strerror(errno));
return VO_ERROR;
}
fcntl(fd, F_ADD_SEALS, F_SEAL_SHRINK | F_SEAL_SEAL);
if (posix_fallocate(fd, 0, size) == 0)
return fd;
close(fd);
MP_ERR(vo, "Failed to allocate memfd: %s\n", mp_strerror(errno));
return VO_ERROR;
#endif
}
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 06:01:21 +02:00
bool vo_wayland_check_visible(struct vo *vo)
{
struct vo_wayland_state *wl = vo->wl;
player: add --force-render option mpv has an internal optimization on a couple of platforms where it will not render any frames if the window is minimized or hidden. There's at least once possible use case for wanting to force a render anyway (screensharing with pipeware) so let's just add a simple switch for this that always forces mpv to render. Closes #10846.
2022-11-11 20:57:53 +01:00
bool render = !wl->hidden || wl->vo_opts->force_render;
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 06:01:21 +02:00
wl->frame_wait = true;
return render;
}
wayland_common: make function declaration consistent Half the code had a space before the arguments and half didn't.
2016-07-21 14:28:58 +02:00
int vo_wayland_control(struct vo *vo, int *events, int request, void *arg)
video/out: introduce vo_control for gl_common based VOs Instead of having separate callbacks for each backend-handled feature (like MPGLContext.fullscreen, MPGLContext.border, etc.), pass the VOCTRL responsible for this directly to the backend. This allows removing a bunch of callbacks, that currently must be set even for optional/lesser features (like VOCTRL_BORDER). This requires changes to all VOs using gl_common, as well as all backends that support gl_common. Also introduce VOCTRL_CHECK_EVENTS. vo.check_events is now optional. VO backends can use VOCTRL_CHECK_EVENTS instead to implementing check_events. This has the advantage that the event handling code in VOs doesn't have to be duplicated if vo_control() is used.
2013-05-15 18:17:18 +02:00
{
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
struct vo_wayland_state *wl = vo->wl;
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
struct mp_vo_opts *opts = wl->vo_opts;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
wl_display_dispatch_pending(wl->display);
wayland: use VOCTRL_SET_CURSOR_VISIBILITY
2013-05-19 13:04:59 +02:00
video/out: introduce vo_control for gl_common based VOs Instead of having separate callbacks for each backend-handled feature (like MPGLContext.fullscreen, MPGLContext.border, etc.), pass the VOCTRL responsible for this directly to the backend. This allows removing a bunch of callbacks, that currently must be set even for optional/lesser features (like VOCTRL_BORDER). This requires changes to all VOs using gl_common, as well as all backends that support gl_common. Also introduce VOCTRL_CHECK_EVENTS. vo.check_events is now optional. VO backends can use VOCTRL_CHECK_EVENTS instead to implementing check_events. This has the advantage that the event handling code in VOs doesn't have to be duplicated if vo_control() is used.
2013-05-15 18:17:18 +02:00
switch (request) {
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
case VOCTRL_CHECK_EVENTS: {
check_dnd_fd(wl);
*events |= wl->pending_vo_events;
wayland: always start rendering after a resize The wayland backend contains logic to detect if the window is hidden. If so, we skip rendering as an optimization. However, if we receive multiple resize events in rapid succession, we will send the compositor new buffers faster than the refresh rate of the monitor. Therefore the compositor will not send us frame events which we incorrectly interpret as the window being hidden. Once the last buffer has actually been rendered, the compositor sends us a frame event. However, if at that point playback is paused, there is no logic to restart rendering of frames that we skipped due to the above optimization. Therefore we never send the compositor new buffers corresponding to the new size of the window and the surface will either be too small or too large. The simplest solution is to always render a few frames after we receive a resize event.
2022-02-02 22:36:05 +01:00
if (*events & VO_EVENT_RESIZE) {
*events |= VO_EVENT_EXPOSE;
wl->frame_wait = false;
wl->timeout_count = 0;
wl->hidden = false;
}
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wl->pending_vo_events = 0;
return VO_TRUE;
}
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
case VOCTRL_VO_OPTS_CHANGED: {
void *opt;
while (m_config_cache_get_next_changed(wl->vo_opts_cache, &opt)) {
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
if (opt == &opts->appid)
update_app_id(wl);
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
if (opt == &opts->border)
{
// This is stupid but the value of border shouldn't be written
// unless we get a configure event. Change it back to its old
// value and let configure_decorations handle it after the request.
if (wl->xdg_toplevel_decoration) {
video/out/wayland_common: don't pass a negative of border flag into ternary Make it clear that we are passing the original requested border mode on.
2022-10-22 18:40:37 +02:00
int requested_border_mode = opts->border;
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
opts->border = !opts->border;
m_config_cache_write_opt(wl->vo_opts_cache,
&opts->border);
video/out/wayland_common: make decoration state usage explicit It is verbose, but makes it more explicit that requested_decoration takes in three values: * 0: no specific mode requested by mpv * ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border) * ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
2022-10-22 11:50:18 +02:00
request_decoration_mode(
video/out/wayland_common: don't pass a negative of border flag into ternary Make it clear that we are passing the original requested border mode on.
2022-10-22 18:40:37 +02:00
wl, requested_border_mode ?
video/out/wayland_common: make decoration state usage explicit It is verbose, but makes it more explicit that requested_decoration takes in three values: * 0: no specific mode requested by mpv * ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border) * ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
2022-10-22 11:50:18 +02:00
ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE :
ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE);
wayland: further xdg-decoration/border refinements The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
2021-08-11 04:17:42 +02:00
} else {
opts->border = false;
m_config_cache_write_opt(wl->vo_opts_cache,
&wl->vo_opts->border);
}
}
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
if (opt == &opts->content_type)
set_content_type(wl);
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
if (opt == &opts->fullscreen)
wayland: don't exit the option loop More than one option may change at the same time so don't break out of this loop.
2020-01-04 22:51:09 +01:00
toggle_fullscreen(wl);
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
if (opt == &opts->hidpi_window_scale)
wayland: handle runtime hidpi-window-scale changes correctly Semi-regression although this option never really did what the manual said until recently. In the past, this option also controlled whether or not mpv set the wayland buffer_scale to the value of the wl_output or force it 1. This had varying effects depending on the exact compositor configuration. That logic has now all been removed and this option now only controls whether or not to scale the window with the hidpi scale factor we get from the compositor. i.e. it actually does what the manual says now.
2023-01-26 20:17:39 +01:00
set_geometry(wl, true);
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
if (opt == &opts->window_maximized)
wayland: don't exit the option loop More than one option may change at the same time so don't break out of this loop.
2020-01-04 22:51:09 +01:00
toggle_maximized(wl);
wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.
2021-06-28 18:03:51 +02:00
if (opt == &opts->window_minimized)
do_minimize(wl);
wayland: update geometry/autofit opts on runtime Additionally, do some cleanups in the resize/autofitting code to make sure we don't do any wasteful VO_EVENT_RESIZE calls. Note that if set_geometry is called, we must always perform a resize.
2020-12-13 22:03:34 +01:00
if (opt == &opts->geometry || opt == &opts->autofit ||
opt == &opts->autofit_smaller || opt == &opts->autofit_larger)
{
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
set_geometry(wl, true);
wayland: update geometry/autofit opts on runtime Additionally, do some cleanups in the resize/autofitting code to make sure we don't do any wasteful VO_EVENT_RESIZE calls. Note that if set_geometry is called, we must always perform a resize.
2020-12-13 22:03:34 +01:00
}
wayland: update Maximize and Minimize handling to use new options I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
2019-11-30 03:00:49 +01:00
}
return VO_TRUE;
}
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
case VOCTRL_CONTENT_TYPE: {
#if HAVE_WAYLAND_PROTOCOLS_1_27
vo_wayland: fix warning -Wvoid-pointer-to-enum-cast
2023-02-25 05:53:42 +01:00
wl->current_content_type = *(enum mp_content_type *)arg;
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
set_content_type(wl);
#endif
return VO_TRUE;
}
command: add read-only focused property Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
2020-09-07 18:22:25 +02:00
case VOCTRL_GET_FOCUSED: {
*(bool *)arg = wl->focused;
return VO_TRUE;
}
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
case VOCTRL_GET_DISPLAY_NAMES: {
*(char ***)arg = get_displays_spanned(wl);
return VO_TRUE;
}
case VOCTRL_GET_UNFS_WINDOW_SIZE: {
int *s = arg;
wayland: report correct window size when maximized In wayland_common, wl->window_size keeps track of the window's size when it is not in the fullscreen or maximized state. GET_UNFS_WINDOW_SIZE is meant to report the size except for when it is fullscreen (hence UNFS). However, the actual function was merely returning the wl->window_size so it was wrong for maximized windows. Workaround this by returning wl->geometry instead when we have the maximized case. Fixes #9207.
2021-09-13 20:45:17 +02:00
if (wl->vo_opts->window_maximized) {
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
s[0] = mp_rect_w(wl->geometry);
s[1] = mp_rect_h(wl->geometry);
wayland: report correct window size when maximized In wayland_common, wl->window_size keeps track of the window's size when it is not in the fullscreen or maximized state. GET_UNFS_WINDOW_SIZE is meant to report the size except for when it is fullscreen (hence UNFS). However, the actual function was merely returning the wl->window_size so it was wrong for maximized windows. Workaround this by returning wl->geometry instead when we have the maximized case. Fixes #9207.
2021-09-13 20:45:17 +02:00
} else {
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
s[0] = mp_rect_w(wl->window_size);
s[1] = mp_rect_h(wl->window_size);
wayland: report correct window size when maximized In wayland_common, wl->window_size keeps track of the window's size when it is not in the fullscreen or maximized state. GET_UNFS_WINDOW_SIZE is meant to report the size except for when it is fullscreen (hence UNFS). However, the actual function was merely returning the wl->window_size so it was wrong for maximized windows. Workaround this by returning wl->geometry instead when we have the maximized case. Fixes #9207.
2021-09-13 20:45:17 +02:00
}
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
return VO_TRUE;
}
case VOCTRL_SET_UNFS_WINDOW_SIZE: {
int *s = arg;
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
wl->window_size.x0 = 0;
wl->window_size.y0 = 0;
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
wl->window_size.x1 = s[0];
wl->window_size.y1 = s[1];
wayland: correct window-scale behavior The way the window-scale option is supposed to behave wasn't really ever documented until 25cfc81. It turns out that different OS/WMs may do slightly different things. For wayland, we need to fix two things. First, only return the wl->window_size in GET_UNFS (aka don't return the fullscreen size). For SET_UNFS, we need to change the behavior for the maximized window case. If the window is maximized, first attempt to unmaximize it and send the wayland event. If the compositor allows this to happen, then go ahead and set the new dimensions and resize it. In the case that the attempt to unmaximize is not successful, then don't attempt the resize and just save the window size dimensions for later to be used when the user unmaximizes the window.
2021-08-08 01:07:09 +02:00
if (!wl->vo_opts->fullscreen) {
if (wl->vo_opts->window_maximized) {
xdg_toplevel_unset_maximized(wl->xdg_toplevel);
wl_display_dispatch_pending(wl->display);
/* Make sure the compositor let us unmaximize */
if (wl->vo_opts->window_maximized)
return VO_TRUE;
}
wayland: refactor geometry/window handling The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
2020-08-18 19:55:01 +02:00
wl->geometry = wl->window_size;
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
wl->pending_vo_events |= VO_EVENT_RESIZE;
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
}
wayland_common: implement output tracking, cleanups and bugfixes This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
2017-10-09 03:08:36 +02:00
return VO_TRUE;
}
case VOCTRL_GET_DISPLAY_FPS: {
if (!wl->current_output)
return VO_NOTAVAIL;
*(double *)arg = wl->current_output->refresh_rate;
return VO_TRUE;
}
command: add display-width/display-height property For some reason, this never existed before. Add VOCTRL_GET_DISPLAY_RES and use it to obtain the current display's resolution from each vo/windowing backend if applicable. Users can then access the current display resolution as display-width and display-height as per the client api. Note that macOS/cocoa was not attempted in this commit since the author has no clue how to write swift.
2021-04-12 19:51:41 +02:00
case VOCTRL_GET_DISPLAY_RES: {
if (!wl->current_output)
return VO_NOTAVAIL;
((int *)arg)[0] = wl->current_output->geometry.x1;
((int *)arg)[1] = wl->current_output->geometry.y1;
return VO_TRUE;
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
case VOCTRL_GET_HIDPI_SCALE: {
if (!wl->scaling)
return VO_NOTAVAIL;
*(double *)arg = wl->scaling;
return VO_TRUE;
}
case VOCTRL_UPDATE_WINDOW_TITLE:
return update_window_title(wl, (const char *)arg);
case VOCTRL_SET_CURSOR_VISIBILITY:
if (!wl->pointer)
return VO_NOTAVAIL;
return set_cursor_visibility(wl, *(bool *)arg);
case VOCTRL_KILL_SCREENSAVER:
return set_screensaver_inhibitor(wl, true);
case VOCTRL_RESTORE_SCREENSAVER:
return set_screensaver_inhibitor(wl, false);
}
return VO_NOTIMPL;
}
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
void vo_wayland_handle_fractional_scale(struct vo_wayland_state *wl)
{
if (wl->fractional_scale_manager && wl->viewport)
wp_viewport_set_destination(wl->viewport,
round(mp_rect_w(wl->geometry) / wl->scaling),
round(mp_rect_h(wl->geometry) / wl->scaling));
}
vo: change vo_platform_init to bool There's several functions that are used for initializing mpv on a certain platform (x11, wayland, etc.). These currently are all int, but they actually return 1 and 0 like a boolean. This gets a bit confusing because actual vo preinit functions return 0 and -1 instead. Just make these all bool instead and return true/false to make it clearer.
2023-01-08 20:16:47 +01:00
bool vo_wayland_init(struct vo *vo)
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
{
vo->wl = talloc_zero(NULL, struct vo_wayland_state);
struct vo_wayland_state *wl = vo->wl;
*wl = (struct vo_wayland_state) {
.display = wl_display_connect(NULL),
.vo = vo,
.log = mp_log_new(wl, vo->log, "wayland"),
wayland: add support for configure bounds In wayland-protocols 1.25, xdg-shell got a version bump which added the configure_bounds event. The compositor can send this to clients to indicate that they should not resize past a certain size. For mpv, we'll choose to only listen to this on reconfig events (i.e. when the window first appears and if the video resolution changes later in the playlist). However, this behavior is still exposed as a user option (default on) because it will neccesarily conflict with a user setting a specific geometry size and/or window scale. Presumably, if someone is setting a really large size that goes beyond the bounds of their monitor, they actually want it like that. The wayland-protocols version is newer-ish, but we can get around having to poke the build system by just using a define that exists in the generated xdg-shell header.
2022-05-31 15:36:15 +02:00
.bounded_width = 0,
.bounded_height = 0,
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 18:49:28 +02:00
.refresh_interval = 0,
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
.scaling = 1,
.wakeup_pipe = {-1, -1},
wayland: initalize display_fd as -1 In the event of a failed wayland initalization, the display_fd is actually 0 instead of -1 which would correctly indicate it doesn't exist. Also move the fd check inside vo_wayland_dispatch_events since that function shouldn't ever do anything if we don't actually have a display fd.
2023-01-01 18:16:31 +01:00
.display_fd = -1,
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
.dnd_fd = -1,
.cursor_visible = true,
.vo_opts_cache = m_config_cache_alloc(wl, vo->global, &vo_sub_opts),
};
wl->vo_opts = wl->vo_opts_cache->opts;
wl_list_init(&wl->output_list);
if (!wl->display)
wayland: cleanup on vo_wayland_init error Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
2023-01-08 20:31:03 +01:00
goto err;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (create_input(wl))
wayland: cleanup on vo_wayland_init error Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
2023-01-08 20:31:03 +01:00
goto err;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->registry = wl_display_get_registry(wl->display);
wl_registry_add_listener(wl->registry, &registry_listener, wl);
/* Do a roundtrip to run the registry */
wl_display_roundtrip(wl->display);
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 02:06:14 +01:00
if (!wl->surface) {
MP_FATAL(wl, "Compositor doesn't support %s (ver. 4)\n",
wl_compositor_interface.name);
wayland: cleanup on vo_wayland_init error Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
2023-01-08 20:31:03 +01: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 02:06:14 +01:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!wl->wm_base) {
MP_FATAL(wl, "Compositor doesn't support the required %s protocol!\n",
xdg_wm_base_interface.name);
wayland: cleanup on vo_wayland_init error Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
2023-01-08 20:31:03 +01:00
goto err;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
if (!wl_list_length(&wl->output_list)) {
MP_FATAL(wl, "No outputs found or compositor doesn't support %s (ver. 2)\n",
wl_output_interface.name);
wayland: cleanup on vo_wayland_init error Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
2023-01-08 20:31:03 +01:00
goto err;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
/* Can't be initialized during registry due to multi-protocol dependence */
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
if (create_viewports(wl))
goto err;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (create_xdg_surface(wl))
wayland: cleanup on vo_wayland_init error Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
2023-01-08 20:31:03 +01:00
goto err;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wayland: don't depend on the order of global announcements E.g. wl_subcompositor could be announced before wl_compositor.
2022-05-28 22:13:23 +02:00
if (wl->subcompositor) {
wl->video_subsurface = wl_subcompositor_get_subsurface(wl->subcompositor, wl->video_surface, wl->surface);
wl_subsurface_set_desync(wl->video_subsurface);
}
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_27
if (wl->content_type_manager) {
wl->content_type = wp_content_type_manager_v1_get_surface_content_type(wl->content_type_manager, wl->surface);
} else {
MP_VERBOSE(wl, "Compositor doesn't support the %s protocol!\n",
wp_content_type_manager_v1_interface.name);
}
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
if (!wl->single_pixel_manager) {
MP_VERBOSE(wl, "Compositor doesn't support the %s protocol!\n",
wp_single_pixel_buffer_manager_v1_interface.name);
}
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
#endif
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_31
if (wl->fractional_scale_manager) {
wl->fractional_scale = wp_fractional_scale_manager_v1_get_fractional_scale(wl->fractional_scale_manager, wl->surface);
wp_fractional_scale_v1_add_listener(wl->fractional_scale, &fractional_scale_listener, wl);
} else {
MP_VERBOSE(wl, "Compositor doesn't support the %s protocol!\n",
wp_fractional_scale_manager_v1_interface.name);
}
#endif
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->dnd_devman && wl->seat) {
wl->dnd_ddev = wl_data_device_manager_get_data_device(wl->dnd_devman, wl->seat);
wl_data_device_add_listener(wl->dnd_ddev, &data_device_listener, wl);
} else if (!wl->dnd_devman) {
MP_VERBOSE(wl, "Compositor doesn't support the %s (ver. 3) protocol!\n",
wl_data_device_manager_interface.name);
wayland: support the display-hidpi-scale property So apparently this property had existed since 2019. Internally, it's used as a part of the console.lua script for scaling. Yours truly somehow didn't bat an eye at the fact that the text in the console was super small (made worse by the fact that xwayland does scale) and just ignored it for all this time. Oh well. To report dpi changes to mpv's core, we need to use VO_EVENT_DPI in a couple of places. One place is, of course, the surface listener if the scale value reported by the wayland server changes. The other place is in the very first reconfig since mpv's core will not find the correct scale value until we actually get a wl_output from the wayland server.
2021-04-12 20:53:10 +02:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->presentation) {
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
wl->fback_pool = talloc_zero(wl, struct vo_wayland_feedback_pool);
wl->fback_pool->wl = wl;
wl->fback_pool->len = 8; // max swapchain depth allowed
wl->fback_pool->fback = talloc_zero_array(wl->fback_pool, struct wp_presentation_feedback *,
wl->fback_pool->len);
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 18:49:28 +02:00
wl->present = talloc_zero(wl, struct mp_present);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
} else {
MP_VERBOSE(wl, "Compositor doesn't support the %s protocol!\n",
wp_presentation_interface.name);
video/out: introduce vo_control for gl_common based VOs Instead of having separate callbacks for each backend-handled feature (like MPGLContext.fullscreen, MPGLContext.border, etc.), pass the VOCTRL responsible for this directly to the backend. This allows removing a bunch of callbacks, that currently must be set even for optional/lesser features (like VOCTRL_BORDER). This requires changes to all VOs using gl_common, as well as all backends that support gl_common. Also introduce VOCTRL_CHECK_EVENTS. vo.check_events is now optional. VO backends can use VOCTRL_CHECK_EVENTS instead to implementing check_events. This has the advantage that the event handling code in VOs doesn't have to be duplicated if vo_control() is used.
2013-05-15 18:17:18 +02:00
}
wayland: introduce vo_wayland_config This removes the need for exposing vo_wayland_fullscreen and other functions also this will be usefull for other vos in the future.
2013-05-16 16:43:34 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->xdg_decoration_manager) {
wl->xdg_toplevel_decoration = zxdg_decoration_manager_v1_get_toplevel_decoration(wl->xdg_decoration_manager, wl->xdg_toplevel);
wayland: handle xdg-decoration protocol better The current usage of the xdg-decoration protocol is quite a bit crude. There's a specific listener struct for this like with most wayland things, but mpv wasn't even using it. It also made no attempt to detect if the compositor was telling mpv to use client side decorations. To implement this correctly, first of all we need to create the decoration listener object and add it like how most wayland things work. Secondly, set_border_decorations needs to be changed to accept the uint32_t mode given by the compositor. When we get the decoration event, pass the mode obtained from the compositor to set_border_decorations. Update the mpv border option, based on whether or not we have server side decorations (yes if we have them; no if we don't). mpv can actually request either client side or server side decorations with this protocol. This function doesn't belong in set_border_decorations but rather it should be called when the border option changes. Whether or not this request actually works depends on the compositor (Plasma appears to allow it; sway does not). If the compositor allows this request, then it gets handled by configure_decorations. Note that the enum strangely starts at 1 hence why there is an extra +1.
2021-08-09 18:40:46 +02:00
zxdg_toplevel_decoration_v1_add_listener(wl->xdg_toplevel_decoration, &decoration_listener, wl);
video/out/wayland_common: make decoration state usage explicit It is verbose, but makes it more explicit that requested_decoration takes in three values: * 0: no specific mode requested by mpv * ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border) * ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
2022-10-22 11:50:18 +02:00
request_decoration_mode(
wl, wl->vo_opts->border ?
ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE :
ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
} else {
wl->vo_opts->border = false;
m_config_cache_write_opt(wl->vo_opts_cache,
&wl->vo_opts->border);
MP_VERBOSE(wl, "Compositor doesn't support the %s protocol!\n",
zxdg_decoration_manager_v1_interface.name);
}
wayland: only warn when actually missing idle inhibit support
2023-01-16 18:29:44 +01:00
if (!wl->idle_inhibit_manager) {
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
MP_VERBOSE(wl, "Compositor doesn't support the %s protocol!\n",
zwp_idle_inhibit_manager_v1_interface.name);
wayland: only warn when actually missing idle inhibit support
2023-01-16 18:29:44 +01:00
const char *xdg_current_desktop = getenv("XDG_CURRENT_DESKTOP");
if (xdg_current_desktop != NULL && strstr(xdg_current_desktop, "GNOME"))
MP_WARN(wl, "GNOME's wayland compositor lacks support for the idle inhibit protocol. This means the screen can blank during playback.\n");
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->opts = mp_get_config_group(wl, wl->vo->global, &wayland_conf);
wl->display_fd = wl_display_get_fd(wl->display);
wayland: rearrange initialization logic cd3b4edea06dec659d9676f2649cc1b1be2e8565 is not correct and had some unexpected breakage with geometry/resizing. Rather than completely revert it, this commit restores the set_surface_scaling call as well as rearranges some other things in the wayland init/reconfig process to make it simplier. The next commit properly fixes what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix.
2022-06-07 17:23:25 +02:00
wayland: set appid before initial surface commit This shouldn't have mattered but apparently qtile is unable to get the app id if you set it after the initial surface commit. Wayland is a mess anyway so just shuffle this around so that the frame callback and surface commit are the last things registered in vo_wayland_init. This works around qtile and, in theory, doesn't appear to break anything else. Fixes #10280.
2022-06-11 17:09:00 +02:00
update_app_id(wl);
mp_make_wakeup_pipe(wl->wakeup_pipe);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->frame_callback = wl_surface_frame(wl->surface);
wl_callback_add_listener(wl->frame_callback, &frame_listener, wl);
wayland: rearrange initialization logic cd3b4edea06dec659d9676f2649cc1b1be2e8565 is not correct and had some unexpected breakage with geometry/resizing. Rather than completely revert it, this commit restores the set_surface_scaling call as well as rearranges some other things in the wayland init/reconfig process to make it simplier. The next commit properly fixes what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix.
2022-06-07 17:23:25 +02:00
wl_surface_commit(wl->surface);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wayland: always do a display_roundtrip at the end of init We really need two roundtrips in the init function. The first one is for running the registry and then second one is for ensuring the xdg_surface and other potential wayland objects are configured at least once before mpv does anything. We've been getting away with only doing the first for a while via luck, but really we should do at least one more wait on the compositor. Fixes #10791 (half of it).
2022-10-27 04:44:23 +02:00
/* Do another roundtrip to ensure all of the above is initialized
* before mpv does anything else. */
wl_display_roundtrip(wl->display);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return true;
wayland: cleanup on vo_wayland_init error Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
2023-01-08 20:31:03 +01:00
err:
vo_wayland_uninit(vo);
return false;
vo_wayland: Wait for frame callbacks Privdes small api for vo_wayland where one can request frame callback and then wait for it. This will make vo_wayland play video smoothly.
2015-08-19 21:41:26 +02:00
}
wayland: make vo_wayland_reconfig a bool This was already returning true/false but the type was int. Also simplify a few places in the wayland contexts where we can just return the value of this function instead of doing redundant checks.
2023-01-08 21:02:13 +01:00
bool vo_wayland_reconfig(struct vo *vo)
wayland: refactor dispatching events This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
2021-05-27 22:22:21 +02:00
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_wayland_state *wl = vo->wl;
wayland: refactor dispatching events This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
2021-05-27 22:22:21 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
MP_VERBOSE(wl, "Reconfiguring!\n");
wayland: refactor dispatching events This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
2021-05-27 22:22:21 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!wl->current_output) {
wl->current_output = find_output(wl);
if (!wl->current_output)
return false;
wayland: rearrange initialization logic cd3b4edea06dec659d9676f2649cc1b1be2e8565 is not correct and had some unexpected breakage with geometry/resizing. Rather than completely revert it, this commit restores the set_surface_scaling call as well as rearranges some other things in the wayland init/reconfig process to make it simplier. The next commit properly fixes what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix.
2022-06-07 17:23:25 +02:00
set_surface_scaling(wl);
wl->pending_vo_events |= VO_EVENT_DPI;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
}
wayland: refactor dispatching events This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
2021-05-27 22:22:21 +02:00
wayland: unbreak runtime geometry/autofit changes Regressed from 879824a47f50f7e93f85992c92d03f37129605f4. The geometry needs to be explictly recalculated now. Change up this function a little bit also give it the ability to directly perform a resize after the fact. This is a common workflow and we'll be using it in the next commit.
2023-01-26 19:53:41 +01:00
set_geometry(wl, false);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wayland: add support for configure bounds In wayland-protocols 1.25, xdg-shell got a version bump which added the configure_bounds event. The compositor can send this to clients to indicate that they should not resize past a certain size. For mpv, we'll choose to only listen to this on reconfig events (i.e. when the window first appears and if the video resolution changes later in the playlist). However, this behavior is still exposed as a user option (default on) because it will neccesarily conflict with a user setting a specific geometry size and/or window scale. Presumably, if someone is setting a really large size that goes beyond the bounds of their monitor, they actually want it like that. The wayland-protocols version is newer-ish, but we can get around having to poke the build system by just using a define that exists in the generated xdg-shell header.
2022-05-31 15:36:15 +02:00
if (wl->opts->configure_bounds)
set_window_bounds(wl);
wayland: rearrange initialization logic cd3b4edea06dec659d9676f2649cc1b1be2e8565 is not correct and had some unexpected breakage with geometry/resizing. Rather than completely revert it, this commit restores the set_surface_scaling call as well as rearranges some other things in the wayland init/reconfig process to make it simplier. The next commit properly fixes what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix.
2022-06-07 17:23:25 +02:00
if ((!wl->vo_opts->fullscreen && !wl->vo_opts->window_maximized) ||
mp_rect_w(wl->geometry) == 0 || mp_rect_h(wl->geometry) == 0)
{
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
wl->geometry = wl->window_size;
wayland: rearrange initialization logic cd3b4edea06dec659d9676f2649cc1b1be2e8565 is not correct and had some unexpected breakage with geometry/resizing. Rather than completely revert it, this commit restores the set_surface_scaling call as well as rearranges some other things in the wayland init/reconfig process to make it simplier. The next commit properly fixes what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix.
2022-06-07 17:23:25 +02:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->vo_opts->fullscreen)
toggle_fullscreen(wl);
if (wl->vo_opts->window_maximized)
toggle_maximized(wl);
if (wl->vo_opts->window_minimized)
do_minimize(wl);
wl->pending_vo_events |= VO_EVENT_RESIZE;
wayland: refactor dispatching events This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
2021-05-27 22:22:21 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
return true;
wayland: refactor dispatching events This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
2021-05-27 22:22:21 +02:00
}
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 17:28:37 +02:00
void vo_wayland_set_opaque_region(struct vo_wayland_state *wl, int alpha)
{
wayland: rewrite geometry and scaling handling This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
2023-01-23 00:06:15 +01:00
const int32_t width = mp_rect_w(wl->geometry);
const int32_t height = mp_rect_h(wl->geometry);
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 17:28:37 +02:00
if (!alpha) {
struct wl_region *region = wl_compositor_create_region(wl->compositor);
wl_region_add(region, 0, 0, width, height);
wl_surface_set_opaque_region(wl->surface, region);
wl_region_destroy(region);
} else {
wl_surface_set_opaque_region(wl->surface, NULL);
}
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
void vo_wayland_uninit(struct vo *vo)
vo_wayland: Wait for frame callbacks Privdes small api for vo_wayland where one can request frame callback and then wait for it. This will make vo_wayland play video smoothly.
2015-08-19 21:41:26 +02:00
{
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
struct vo_wayland_state *wl = vo->wl;
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (!wl)
return;
mp_input_put_key(wl->vo->input_ctx, MP_INPUT_RELEASE_ALL);
if (wl->compositor)
wl_compositor_destroy(wl->compositor);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
if (wl->subcompositor)
wl_subcompositor_destroy(wl->subcompositor);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->current_output && wl->current_output->output)
wl_output_destroy(wl->current_output->output);
if (wl->cursor_surface)
wl_surface_destroy(wl->cursor_surface);
if (wl->cursor_theme)
wl_cursor_theme_destroy(wl->cursor_theme);
wayland: add support for content-type protocol The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
2022-11-15 22:51:45 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_27
if (wl->content_type)
wp_content_type_v1_destroy(wl->content_type);
if (wl->content_type_manager)
wp_content_type_manager_v1_destroy(wl->content_type_manager);
#endif
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->dnd_ddev)
wl_data_device_destroy(wl->dnd_ddev);
if (wl->dnd_devman)
wl_data_device_manager_destroy(wl->dnd_devman);
if (wl->dnd_offer)
wl_data_offer_destroy(wl->dnd_offer);
wayland: store presentation feedbacks in a pool Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
2023-01-14 02:28:46 +01:00
if (wl->fback_pool)
clean_feedback_pool(wl->fback_pool);
Revert "wayland: dispatch and wait for compositor events in uninit" This ended up being a bad idea. The problem is that it introduces ordering when destroying events (something we weren't worried about before) and Lynne pointed out a problem with the callback not also being destroyed before the surface in IRC. Just undo this and go with a different approach (next commit). P.S. the wayland_dispatch_events name change is kept though because I like that better. This reverts commit aa8ddfcdf30c4ffb38f3ec5d6663bbabf0b7b4df.
2023-01-14 05:03:00 +01:00
wayland: add wp-fractional-scale-v1 support This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
2023-01-23 21:16:43 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_31
if (wl->fractional_scale)
wp_fractional_scale_v1_destroy(wl->fractional_scale);
if (wl->fractional_scale_manager)
wp_fractional_scale_manager_v1_destroy(wl->fractional_scale_manager);
#endif
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->frame_callback)
wl_callback_destroy(wl->frame_callback);
if (wl->idle_inhibitor)
zwp_idle_inhibitor_v1_destroy(wl->idle_inhibitor);
if (wl->idle_inhibit_manager)
zwp_idle_inhibit_manager_v1_destroy(wl->idle_inhibit_manager);
if (wl->keyboard)
wl_keyboard_destroy(wl->keyboard);
if (wl->pointer)
wl_pointer_destroy(wl->pointer);
if (wl->presentation)
wp_presentation_destroy(wl->presentation);
if (wl->registry)
wl_registry_destroy(wl->registry);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
if (wl->viewporter)
wayland: free dmabuf_feedback object 666cb91cf12a4f8b42087530104513b0fc4ba16d added dmabuf_feedback, but it was never actually free'd on uninit. Because this function requires wayland protocols 1.24, we have to wrap it in an #if. Also throw in some minor cosmetic changes in here.
2022-10-29 22:51:02 +02:00
wp_viewporter_destroy(wl->viewporter);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
if (wl->viewport)
wayland: free dmabuf_feedback object 666cb91cf12a4f8b42087530104513b0fc4ba16d added dmabuf_feedback, but it was never actually free'd on uninit. Because this function requires wayland protocols 1.24, we have to wrap it in an #if. Also throw in some minor cosmetic changes in here.
2022-10-29 22:51:02 +02:00
wp_viewport_destroy(wl->viewport);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
if (wl->video_viewport)
wayland: free dmabuf_feedback object 666cb91cf12a4f8b42087530104513b0fc4ba16d added dmabuf_feedback, but it was never actually free'd on uninit. Because this function requires wayland protocols 1.24, we have to wrap it in an #if. Also throw in some minor cosmetic changes in here.
2022-10-29 22:51:02 +02:00
wp_viewport_destroy(wl->video_viewport);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
if (wl->dmabuf)
wayland: free dmabuf_feedback object 666cb91cf12a4f8b42087530104513b0fc4ba16d added dmabuf_feedback, but it was never actually free'd on uninit. Because this function requires wayland protocols 1.24, we have to wrap it in an #if. Also throw in some minor cosmetic changes in here.
2022-10-29 22:51:02 +02:00
zwp_linux_dmabuf_v1_destroy(wl->dmabuf);
#if HAVE_WAYLAND_PROTOCOLS_1_24
if (wl->dmabuf_feedback)
zwp_linux_dmabuf_feedback_v1_destroy(wl->dmabuf_feedback);
#endif
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->seat)
wl_seat_destroy(wl->seat);
if (wl->shm)
wl_shm_destroy(wl->shm);
vo_dmabuf_wayland: use single-pixel-buffer-v1 The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
2022-11-16 02:52:56 +01:00
#if HAVE_WAYLAND_PROTOCOLS_1_27
if (wl->single_pixel_manager)
wp_single_pixel_buffer_manager_v1_destroy(wl->single_pixel_manager);
#endif
Revert "wayland: dispatch and wait for compositor events in uninit" This ended up being a bad idea. The problem is that it introduces ordering when destroying events (something we weren't worried about before) and Lynne pointed out a problem with the callback not also being destroyed before the surface in IRC. Just undo this and go with a different approach (next commit). P.S. the wayland_dispatch_events name change is kept though because I like that better. This reverts commit aa8ddfcdf30c4ffb38f3ec5d6663bbabf0b7b4df.
2023-01-14 05:03:00 +01:00
if (wl->surface)
wl_surface_destroy(wl->surface);
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 16:35:53 +02:00
if (wl->video_surface)
wl_surface_destroy(wl->video_surface);
if (wl->video_subsurface)
wl_subsurface_destroy(wl->video_subsurface);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->wm_base)
xdg_wm_base_destroy(wl->wm_base);
if (wl->xdg_decoration_manager)
zxdg_decoration_manager_v1_destroy(wl->xdg_decoration_manager);
Revert "wayland: dispatch and wait for compositor events in uninit" This ended up being a bad idea. The problem is that it introduces ordering when destroying events (something we weren't worried about before) and Lynne pointed out a problem with the callback not also being destroyed before the surface in IRC. Just undo this and go with a different approach (next commit). P.S. the wayland_dispatch_events name change is kept though because I like that better. This reverts commit aa8ddfcdf30c4ffb38f3ec5d6663bbabf0b7b4df.
2023-01-14 05:03:00 +01:00
if (wl->xdg_toplevel)
xdg_toplevel_destroy(wl->xdg_toplevel);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->xdg_toplevel_decoration)
zxdg_toplevel_decoration_v1_destroy(wl->xdg_toplevel_decoration);
Revert "wayland: dispatch and wait for compositor events in uninit" This ended up being a bad idea. The problem is that it introduces ordering when destroying events (something we weren't worried about before) and Lynne pointed out a problem with the callback not also being destroyed before the surface in IRC. Just undo this and go with a different approach (next commit). P.S. the wayland_dispatch_events name change is kept though because I like that better. This reverts commit aa8ddfcdf30c4ffb38f3ec5d6663bbabf0b7b4df.
2023-01-14 05:03:00 +01:00
if (wl->xdg_surface)
xdg_surface_destroy(wl->xdg_surface);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
if (wl->xkb_context)
xkb_context_unref(wl->xkb_context);
if (wl->xkb_keymap)
xkb_keymap_unref(wl->xkb_keymap);
if (wl->xkb_state)
xkb_state_unref(wl->xkb_state);
if (wl->display) {
close(wl_display_get_fd(wl->display));
wl_display_disconnect(wl->display);
}
wayland: bump dmabuf protocol to version 4 Pulled from https://github.com/mpv-player/mpv/pull/10382 The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor containing both formats and modifiers, which makes it possible for the compositor to import the buffers onto planes using explicit modifiers. This is an extremely important efficiency improvement, as the 3D hardware can be left powered off altogether, the vaapi buffer being sent directly from the video hardware to the display controller. It could be possible to support zwp_linux_dmabuf_v1 version 3 as well, but there is no reason beyond compatibility with old stacks. I would recommend to ditch version 2 as well, as modifier-less formats aren’t very useful nowadays.
2022-07-07 12:03:21 +02:00
munmap(wl->format_map, wl->format_size);
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
struct vo_wayland_output *output, *tmp;
wl_list_for_each_safe(output, tmp, &wl->output_list, link)
remove_output(output);
for (int n = 0; n < 2; n++)
close(wl->wakeup_pipe[n]);
talloc_free(wl);
vo->wl = NULL;
wayland: port to the new wakeup/wait_events framework This fits natively into the vo/backend and allows to simplify the polling code. One new change is the fact that surface_handle_enter flags VO_EVENT_WIN_STATE and VO_EVENT_RESIZE instead of only VO_EVENT_WIN_STATE. Before this, the code hackily relied on the timeout and the loop in the wait_frame function to track and set the scaling factor. Instead, this triggers mpv to run a schedule_resize and adjust the new VO output dimensions immediately. This is also more accurate since surface_handle_enter() gets called when a surface is created, moved and resized, which is exactly what the rest of the player might be interested in.
2016-07-21 13:25:30 +02:00
}
vo_wayland: Wait for frame callbacks Privdes small api for vo_wayland where one can request frame callback and then wait for it. This will make vo_wayland play video smoothly.
2015-08-19 21:41:26 +02: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 21:36:19 +02:00
void vo_wayland_wait_frame(struct vo_wayland_state *wl)
wayland: use callback flag + poll for buffer swap The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
2019-10-07 22:58:36 +02:00
{
wayland: workaround hidden state detection badness The wayland code uses a heuristic to determine whether or not the mpv window is hidden since the xdg-shell protocol does not provide a way for a client to directly know this. We don't render with the frame callback function for various, complicated reasons but the tl;dr is that it doesn't work well with mpv's core (maybe an essay should be written on this one day). Currently, the aforementioned heuristic considers a window hidden if we miss more frames in a row than the display's current refresh rate (completely arbitrary number). However, the wayland protocol does allow for the display's refresh rate to be 0 in certain cases (like a virtual output). This completely wrecks the heuristic and basically causes only every other frame to be rendered (real world example: nested sway sessions). Instead let's slightly redesign this mechanism to be a little smarter. For coming up with the vblank time (to predict when to timeout on the wait function), instead use the vsync interval calculated using presentation time. That is the most accurate measure available. If that number is not available/invalid, then we try to use the vsync interval predicted by the presentation event. If we still don't have that (i.e. no presentation time supported by the compositor), we can instead use the old way of using the expected vsync interval from the display's reported refresh rate. If somehow we still do not have a usable number, then just give up and makeup shit. Note that at this point we could technically ask the vo for the estimated vsync jitter, but that would involve locking/unlocking vo which sounds horrifying. Ideally, you never reach here. See https://github.com/swaywm/wlroots/issues/2566 for the actual target of this fix. wlroots uses presentation time so in practice we are mostly just using that calculated vsync interval number.
2021-04-16 21:55:15 +02:00
int64_t vblank_time = 0;
/* We need some vblank interval to use for the timeout in
* this function. The order of preference of values to use is:
* 1. vsync duration from presentation time
* 2. refresh inteval reported by presentation time
* 3. refresh rate of the output reported by the compositor
* 4. make up crap if vblank_time is still <= 0 (better than nothing) */
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 18:05:00 +02: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 18:49:28 +02:00
vblank_time = wl->present->vsync_duration;
wayland: workaround hidden state detection badness The wayland code uses a heuristic to determine whether or not the mpv window is hidden since the xdg-shell protocol does not provide a way for a client to directly know this. We don't render with the frame callback function for various, complicated reasons but the tl;dr is that it doesn't work well with mpv's core (maybe an essay should be written on this one day). Currently, the aforementioned heuristic considers a window hidden if we miss more frames in a row than the display's current refresh rate (completely arbitrary number). However, the wayland protocol does allow for the display's refresh rate to be 0 in certain cases (like a virtual output). This completely wrecks the heuristic and basically causes only every other frame to be rendered (real world example: nested sway sessions). Instead let's slightly redesign this mechanism to be a little smarter. For coming up with the vblank time (to predict when to timeout on the wait function), instead use the vsync interval calculated using presentation time. That is the most accurate measure available. If that number is not available/invalid, then we try to use the vsync interval predicted by the presentation event. If we still don't have that (i.e. no presentation time supported by the compositor), we can instead use the old way of using the expected vsync interval from the display's reported refresh rate. If somehow we still do not have a usable number, then just give up and makeup shit. Note that at this point we could technically ask the vo for the estimated vsync jitter, but that would involve locking/unlocking vo which sounds horrifying. Ideally, you never reach here. See https://github.com/swaywm/wlroots/issues/2566 for the actual target of this fix. wlroots uses presentation time so in practice we are mostly just using that calculated vsync interval number.
2021-04-16 21:55:15 +02:00
if (vblank_time <= 0 && wl->refresh_interval > 0)
vblank_time = wl->refresh_interval;
if (vblank_time <= 0 && wl->current_output->refresh_rate > 0)
vblank_time = 1e6 / wl->current_output->refresh_rate;
// Ideally you should never reach this point.
if (vblank_time <= 0)
vblank_time = 1e6 / 60;
wayland: increase the vblank waiting time This commit sucks bad, but everything else is worse is other ways. Basically, the current vblank waiting time in the vo_wayland_wait_frame function (calculated very carefully using presentation statistics) is randomly too short. Some compositors are quite variable when they actually return callback so our timeout expires too quickly and throws everything off. The fix? Add an arbitrary 5% to the vblank value and pray that nothing gets off that much. Why did they have to make swapinterval 1/fifo mode indefinitely block? Fixes #9504.
2021-11-25 06:37:43 +01:00
// Completely arbitrary amount of additional time to wait.
vblank_time += 0.05 * vblank_time;
wayland: remove wayland-frame-wait-offset option This originally existed as a hack for weston. In certain scenarios, a frame taking too long to render would cause vo_wayland_wait_frame to timeout which would result in a ton of dropped frames. The naive solution was to just to add a slight delay to the time value. If a frame took too long, it would likely to fall under the timeout value and all was well. This was exposed to the user since the default delay (1000) was completely arbitrary. However with presentation time, this doesn't appear to be neccesary. Fresh frames that take longer than the display's refresh rate (16.666 ms in most cases) behave well in Weston. In the other two main compositors without presentation time (GNOME and Plasma), they also do not experience any ill effects. It's better not to overcomplicate things, so this "feature" can be removed now.
2020-01-30 18:19:22 +01:00
int64_t finish_time = mp_time_us() + vblank_time;
wayland: use callback flag + poll for buffer swap The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
2019-10-07 22:58:36 +02:00
wayland: add presentation time Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
2019-10-10 21:14:40 +02:00
while (wl->frame_wait && finish_time > mp_time_us()) {
wayland: adjust vo_wayland_wait_frame logic Wayland uses vo_wayland_wait_frame plus some polling with a timeout for blocking on vsync. Here are a couple of changes that seem to be improvements. First, the poll time is always rounded up instead of truncated. When rendering frames longer than the standard 16.666 ms timeout, it seems that truncating the poll time slightly early may cause some vsync jitter spikes. Waiting longer, even if it's too long, appears to behave better. The second change is to use wl_display_roundtrip instead of wl_display_dispatch_pending. wl_display_dispatch_pending dispatches all events immediately. This is good to avoid blocking, but it's not guaranteed to wait long enough for all events to be processed on the display fd. The preceding wl_display_read_events routine ensures that all events on the display fd are queued. We just need a semi-blocking routine to dispatch them for the most reliable vsync. wl_display_roundtrip will dispatch any events for us, but also wait for a reply from the display server. This makes it ideal for this role. If the compositor doesn't reply to the client something else is probably horribly broken and wrong anyway. It's also not a permanently blocking call like wl_display_dispatch. If there's no frame callback (i.e. the window is hidden), then it does not dispatch any events and returns immediately.
2020-02-07 06:54:57 +01:00
int poll_time = ceil((double)(finish_time - mp_time_us()) / 1000);
wayland: use callback flag + poll for buffer swap The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
2019-10-07 22:58:36 +02:00
if (poll_time < 0) {
poll_time = 0;
}
wayland: dispatch and wait for compositor events in uninit Similar to some other issues we've had with unprocessed compositor events. When quitting mpv, there's two things we should be doing: dispatching any last minute wayland events and then waiting for a compositor reply. Luckily, there's already an internal helper for this (renamed to wayland_dispatch_events for consistency) that we can use. All of the special casing of wl->feedback becomes unneccesary and we can remove this from vo_wayland_state with this method. Fixes #110022.
2023-01-01 03:51:13 +01:00
wayland_dispatch_events(wl, 1, poll_time);
wayland: use callback flag + poll for buffer swap The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
2019-10-07 22:58:36 +02:00
}
wayland: avoid potential deadlocks wl_display_dispatch is dangerous because it will block forever if the event queue is empty. Any direct calls to this function should just be replaced with wl_display_dispatch_pending which accomplishes the same thing for mpv's purposes without any chance of blocking. The other potential trap is wl_display_roundtrip. It can internally call wl_display_dispatch which in certain circumstances could potentially block. There are cases where we need the server to finish processing client requests before doing anything else so this can not be cleanly avoided. The dangerous call is the usage of wl_display_roundtrip in vo_wayland_wait_frame. In the majority of cases, this shouldn't be a problem because the previous wl_display_read_events should always queue up some events on the fd for wl_display_roundtrip to send. However, the compositor could potentially send us an error in the display queue that could lead to bad behavior when wl_display_roundtrip is called. The wl_display_roundtrip can't be removed because we are relying on its semi-blocking capabilities, but the logic can be slightly adjusted to be safer. The obvious thing to do is to make sure we check the pollfd for any errors. If one is returned, then we call wl_display_cancel_read and try again. The less obvious trick is to call wl_display_dispatch_pending and move wl_display_roundtrip outside of the blocking + timeout loop. This change has some subtle but important differences. Previously, vo_wayland_wait_frame would read an event and wait on the server to process it one-by-one. With this change, the events are dispatched as soon as possible to the server and then we wait on all of those (potentially multiple) events to be processed after we have either received frame callback or the loop times out. After that is done, we can then check for if there are any errors on the display. If it's all clear, we can run wl_display_roundtrip without any worries. If some error happens, then don't execute the function at all.
2020-07-30 22:21:57 +02:00
wayland: refactor dispatching events This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
2021-05-27 22:22:21 +02:00
/* If the compositor does not have presentation time, we cannot be sure
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 21:36:19 +02:00
* that this wait is accurate. Do a hacky block with wl_display_roundtrip. */
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 18:05:00 +02:00
if (!wl->use_present && !wl_display_get_error(wl->display))
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 21:36:19 +02:00
wl_display_roundtrip(wl->display);
if (wl->frame_wait) {
// Only consider consecutive missed callbacks.
if (wl->timeout_count > 1) {
wayland: always be sure to initially try to render A subtle regression from c26d833. On sway if mpv was set to be a floating window in the config, set_buffer_scale would actually get applied twice according to the wayland log. That meant a 1920x1080 window would appear as a 960x540 window if the scale of the wl_output was set to 2. This only affected egl on sway (didn't occur on weston and was too lazy to try anything else; probably they were fine). Since wl->render is initially false, that meant that the very first run through the render loop returns false. This probably caused something weird to happen with the set_buffer_scale calls (the egl window gets created and everything but mpv doesn't write to it just yet) which makes the set_buffer_scale call happen an extra time. Since it was always intended for mpv to initally render, this is worth fixing. Just chnage wl->render to wl->hidden (again) and flip the bools around. That way, the initial false value results in render == true and mpv tries to draw on the first pass. This fixes the weird scaling behavior because reasons.
2021-06-27 16:55:33 +02:00
wl->hidden = true;
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 21:36:19 +02:00
return;
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 21:36:59 +02:00
} else {
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 21:36:19 +02:00
wl->timeout_count += 1;
return;
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 21:36:59 +02:00
}
wayland: be less strict about when to render efb0c5c changed the rendering logic of mpv on wayland and made it skip rendering when it did not receive frame callback in time. The idea was to skip rendering when the surface was hidden and be less wasteful. This unfortunately had issues in certain instances where a frame callback could be missed (but the window was still in view) due to imprecise rendering (like the default audio video-sync mode). This would lead to the video appearing to stutter since mpv would skip rendering in those cases. To account for this case, simply re-add an old heuristic for detecting if a window is hidden or not since the goal is to simply not render when a window is hidden. If the wait on the frame callback times out enough times in a row, then we consider the window hidden and thus begin to skip rendering then. The actual threshold to consider a surface as hidden is completely arbitrary (greater than your monitor's refresh rate), but it's safe enough since realistically you're not going to miss 60+ frame callbacks in a row unless the surface actually is hidden. Fixes #8169.
2020-10-13 17:36:08 +02: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 21:36:19 +02:00
wl->timeout_count = 0;
wayland: use callback flag + poll for buffer swap The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
2019-10-07 22:58:36 +02:00
}
wayland: port to the new wakeup/wait_events framework This fits natively into the vo/backend and allows to simplify the polling code. One new change is the fact that surface_handle_enter flags VO_EVENT_WIN_STATE and VO_EVENT_RESIZE instead of only VO_EVENT_WIN_STATE. Before this, the code hackily relied on the timeout and the loop in the wait_frame function to track and set the scaling factor. Instead, this triggers mpv to run a schedule_resize and adjust the new VO output dimensions immediately. This is also more accurate since surface_handle_enter() gets called when a surface is created, moved and resized, which is exactly what the rest of the player might be interested in.
2016-07-21 13:25:30 +02:00
void vo_wayland_wait_events(struct vo *vo, int64_t until_time_us)
{
wayland_common: rewrite from scratch The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
2017-10-01 22:16:49 +02:00
struct vo_wayland_state *wl = vo->wl;
wayland: port to the new wakeup/wait_events framework This fits natively into the vo/backend and allows to simplify the polling code. One new change is the fact that surface_handle_enter flags VO_EVENT_WIN_STATE and VO_EVENT_RESIZE instead of only VO_EVENT_WIN_STATE. Before this, the code hackily relied on the timeout and the loop in the wait_frame function to track and set the scaling factor. Instead, this triggers mpv to run a schedule_resize and adjust the new VO output dimensions immediately. This is also more accurate since surface_handle_enter() gets called when a surface is created, moved and resized, which is exactly what the rest of the player might be interested in.
2016-07-21 13:25:30 +02:00
int64_t wait_us = until_time_us - mp_time_us();
x11, wayland: always round up wait times If wait_us is >0 and <500, the wait time gets rounded down 0, effectively turning this into busy waiting. Round it up instead.
2016-08-26 20:22:33 +02:00
int timeout_ms = MPCLAMP((wait_us + 999) / 1000, 0, 10000);
vo_wayland: Wait for frame callbacks Privdes small api for vo_wayland where one can request frame callback and then wait for it. This will make vo_wayland play video smoothly.
2015-08-19 21:41:26 +02:00
wayland: dispatch and wait for compositor events in uninit Similar to some other issues we've had with unprocessed compositor events. When quitting mpv, there's two things we should be doing: dispatching any last minute wayland events and then waiting for a compositor reply. Luckily, there's already an internal helper for this (renamed to wayland_dispatch_events for consistency) that we can use. All of the special casing of wl->feedback becomes unneccesary and we can remove this from vo_wayland_state with this method. Fixes #110022.
2023-01-01 03:51:13 +01:00
wayland_dispatch_events(wl, 2, timeout_ms);
vo_wayland: Wait for frame callbacks Privdes small api for vo_wayland where one can request frame callback and then wait for it. This will make vo_wayland play video smoothly.
2015-08-19 21:41:26 +02:00
}
wayland: reorganize wayland common code Mostly a cosmetic change that (hopefully) makes things look better. Some functions and structs that were previously being exported in the wayland header were made static to the wayland_common.c file (these shouldn't be accessed by anyone else).
2021-06-26 23:12:03 +02:00
void vo_wayland_wakeup(struct vo *vo)
{
struct vo_wayland_state *wl = vo->wl;
(void)write(wl->wakeup_pipe[1], &(char){0}, 1);
}
Copy Permalink