This adds a "native" Wayland clipboard backend based on the
ext-data-control-v1 protocol.
This backend overcomes the limitation of the VO (Wayland core protocol)
backend, and does not require the presence of the VO window to receive clipboard
updates.
This backend also supports primary selection if supported by the compositor.
The backend runs in a separate thread, so clipboard reading
does not stall the player like the VO backend.
This is useful for text input in, for example, console.lua. Each
character in the commit string gets turned into an mpv key press.
Pre-edit strings are not handled, since there's currently no good way to
handle that or make it useful to text input scripts. Like win32, which I
tested in wine, another limitation is that the composition window is
always positioned at the top left of the window, since we cannot get
useful positioning hints from mpv scripts. It allows the composition
window to be within the window and avoids obstructing the console
prompt.
This can be enabled/disabled with --input-ime=<yes|no> (default: yes).
Although this protocol isn't official yet, several compositors are known
to support it to some extent and this lets users actually view HDR with
less hacks/workarounds. The actual protocol here is simply copy and
pasted from the upstream fork* where these are developed. There is also
icc profile support in the protocol, but this is omitted for now in
favor of setting colorspaces and signalling hdr metadata. However for
mpv, this only actually has any practical use with vo_dmabuf_wayland so
this is the only VO that will make use of the protocol. When using
vulkan, this is already handled via vulkan extensions by compositors and
vo_gpu_next. So actually we don't want to use the wayland protocol in
that case since it will just get in the way. The only known limitation
on that front is driver support for hdr vulkan surfaces but as soon as
that is available it should just work with no code changes. For opengl,
hdr support there is a whole other mess with a lot of unknowns but
simply using this protocol isn't good enough and would require changes
elsewhere. vo_wlshm is currently too stupid to pick any format besides
bgr0 or 0rgb, so any color management there is meaningless at this
stage.
So this means that only vo_dmabuf_wayland can actually use this
protocol. But that's perfectly fine. Without this, vo_dmabuf_wayland has
a very bad limitation in that it cannot communicate colorspaces at all
and compositors have to guess. Using xx-color-management-v4 fixes this.
For the other VOs, merely having the common protocol setup stuff in the
common code does no harm and later if they get smarter, it's easy for
them to use the stuff since it is written generically anyway.
*: https://gitlab.freedesktop.org/swick/wayland-protocols/-/tree/color-xx/staging/color-management
This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
nanahi