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

49 lines
2.2 KiB
Meson
Raw Normal View History

meson: add internal arg to wayland-protocols' get_variable() This allows developers to build mpv with a wayland-protocols subproject.
2022-06-03 15:39:50 +00:00
wl_protocol_dir = wayland['deps'][2].get_variable(pkgconfig: 'pkgdatadir', internal: 'pkgdatadir')
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 14:35:53 +00:00
protocols = [[wl_protocol_dir, 'stable/presentation-time/presentation-time.xml'],
[wl_protocol_dir, 'stable/viewporter/viewporter.xml'],
[wl_protocol_dir, 'stable/xdg-shell/xdg-shell.xml'],
build: add meson build support Adds support for the meson build system as well as a bit of documentation. Compatibility with the existing waf build is maintained.
2021-11-07 19:28:16 +00:00
[wl_protocol_dir, 'unstable/idle-inhibit/idle-inhibit-unstable-v1.xml'],
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 14:35:53 +00:00
[wl_protocol_dir, 'unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml'],
wayland: bump wayland-protocol requirement to 1.31 And wayland-client/cursor to 1.21 Debian Stable has these
2024-07-05 15:35:57 +00:00
[wl_protocol_dir, 'unstable/xdg-decoration/xdg-decoration-unstable-v1.xml'],
[wl_protocol_dir, 'staging/content-type/content-type-v1.xml'],
wayland: add support for xx-color-management-v4 for vo_dmabuf_wayland 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
2024-09-26 22:28:35 +00:00
[wl_protocol_dir, 'staging/fractional-scale/fractional-scale-v1.xml'],
wayland: bump wayland-protocol requirement to 1.31 And wayland-client/cursor to 1.21 Debian Stable has these
2024-07-05 15:35:57 +00:00
[wl_protocol_dir, 'staging/single-pixel-buffer/single-pixel-buffer-v1.xml'],
wayland: add support for xx-color-management-v4 for vo_dmabuf_wayland 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
2024-09-26 22:28:35 +00:00
['protocols', 'xx-color-management-v4.xml']]
build: add meson build support Adds support for the meson build system as well as a bit of documentation. Compatibility with the existing waf build is maintained.
2021-11-07 19:28:16 +00:00
wl_protocols_source = []
wl_protocols_headers = []
wayland: bump wayland-protocol requirement to 1.31 And wayland-client/cursor to 1.21 Debian Stable has these
2024-07-05 15:35:57 +00:00
foreach v: ['1.32']
meson: rename all features with underscores The convention is to use dashes.
2023-08-20 20:40:58 +00:00
features += {'wayland-protocols-' + v.replace('.', '-'):
wayland['deps'][2].version().version_compare('>=' + v)}
endforeach
if features['wayland-protocols-1-32']
wayland: add cursor-shape-v1 support This protocol no longer requires us to draw a separate cursor surface and all of that horrible stuff. We can just ask the compositor for the default cursor instead since that's literally all mpv cares about.
2023-05-19 22:07:25 +00:00
protocols += [[wl_protocol_dir, 'staging/cursor-shape/cursor-shape-v1.xml'],
[wl_protocol_dir, 'unstable/tablet/tablet-unstable-v2.xml']] # required by cursor-shape
endif
build: add meson build support Adds support for the meson build system as well as a bit of documentation. Compatibility with the existing waf build is maintained.
2021-11-07 19:28:16 +00:00
foreach p: protocols
xml = join_paths(p)
wl_protocols_source += custom_target(xml.underscorify() + '_c',
input: xml,
output: '@BASENAME@.c',
command: [wayland['scanner'], 'private-code', '@INPUT@', '@OUTPUT@'],
)
wl_protocols_headers += custom_target(xml.underscorify() + '_h',
input: xml,
output: '@BASENAME@.h',
command: [wayland['scanner'], 'client-header', '@INPUT@', '@OUTPUT@'],
)
endforeach
lib_client_protocols = static_library('protocols',
wl_protocols_source + wl_protocols_headers,
dependencies: wayland['deps'][0])
client_protocols = declare_dependency(link_with: lib_client_protocols,
sources: wl_protocols_headers)
dependencies += [client_protocols, wayland['deps']]
build: remove outdated generated directory 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.
2023-07-23 22:54:35 +00:00
sources += files('wayland_common.c')