While most Wayland compositors provide a socket path indicated by
environment variable WAYLAND_DISPLAY, others may sometimes bequeath a
socket file descriptor specified by WAYLAND_SOCKET.
82231fd74d mentioned that for the "rot"
transform flip=true must be set, which "makes no sense at all".
The reason this is happening is that the rotation matrix calculation
is only valid for the 2D coordinate system where y axis is 90 degrees
counterclockwise from x axis, but the coordinate system of chroma
offset has its origin at top-left so it is the opposite, which results
in the rotation going to the opposite way. Setting flip=true fixes the
rotation direction, but results in a flipped y coordinate.
Fix this by reversing the rotation angle for chroma offset rotation
matrix calculation. This also allows removing some duplicated code.
The libplacebo colorspace hint api makes sense for things like vulkan,
but for other APIs like drm that are capable of directly handling
colorspaces and hdr metadata it's a nuisance. Add a pass_colorspace fns
that signals to vo_gpu_next that the backend doesn't need the color
information to be manipulated and can handle the metadata itself.
libdrm unfortunately doesn't give us what is actually supported by the
connector in question. To do that, we would have to parse the edid blob.
Use libdisplay-info to do this and make it required for drm support.
Using what we get back from the library, we can do a bit of sanity
checking for hdr metadata to make sure that the display in question can
handle it before we try setting the metadata. Strictly speaking,
libdisplay-info has stuff for dynamic metadata that we could potentially
use, but as a first pass and for simplicity, only static is considered
for now.
The geometry output of vo_calc_window_geometry does not have
any information about the current window position. This causes
the window to move when setting geometry even without setting
x/y.
Change it so that the window position is unchanged if x/y are not
set and after startup.
For most actual desktop users, vulkan should be the a superior
experience over opengl as this point and our autoprobe should pick that.
For linux users, vulkan on wayland is rapidly seeing improvements and is
far ahead of egl. There is no sign of that changing anytime soon and
working fifo is on the horizon, so really wayland users should just all
be using vulkan from now on. For x11, there is not a big difference
between using egl vs vulkan as far as I know and both work well. macOS
already prefers the vulkan backend over the libmpv one anyways, and
finally windows still defaults to d3d11. Probably virtually no one uses
opengl on windows, but vulkan is reasonably common among windows users
and it doesn't make any sense to prefer opengl over it.
The two outliers here are Android and VK_KHR_display. On Android, vulkan
drivers are probably just a total disaster and let's not put ourselves
in that mess if there's no reason to. For VK_KHR_display, it actually
works fine except for one really big problem: VT switching doesn't work.
If you try it, enjoy losing all input and being forced to do a hard
reboot. It might be fixable if you use logind or something, but the
method of using signals like the drm context does won't work because
VK_KHR_display uses render nodes not primary nodes. Also, the opengl drm
context could support hdr in theory (some attempts were made but none
succesful) so it is probably "better". Maybe. Anyways, for these two
platforms, we still prefer opengl.
this effectively disables the workaround that picks the color/dither
depth based on the source and instead picks it based on the output
surface/pixel format.
macOS apparently always operates at 10bit internally regardless of the
display's bit depth. this changed at some point in the more recent macOS
versions, where previously macOS operated at a frame buffer depth
corresponding to the display. either 30-Bit Color (ARGB2101010) for
10bit or 24-Bit Color (ARGB8888) for 8bit.
Fixes#13767
First of all, `lutdata` was passed to `pl_lut_parse_cube()` even if
it was empty. This caused a bogus error message to be printed by
the LUT parsing code in libplacebo.
"[vo/gpu-next/libplacebo] Missing LUT size specification?"
One of the reasons why `lutdata` can be empty is if the LUT file size
exceeds the `max_size` limit passed to `stream_read_file()`.
So in this commit, `lutdata` is checked first before getting passed to
libplacebo, and a non-bogus error message is printed if it's empty.
And secondly, the max size allowed is raised from the quite limiting
value of 100MB to 1.5GiB. The new max matches the limit in LUT cache
which is used to support up to 512x512x512 LUTs.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
When the present extension was originally implemented, nvidia was
specifically blacklisted. The reason was because at the time it would
give bogus values that appeared to be real but actively made playback
worse. So out of an abundance of caution, any nvidia detection at all
(e.g. on a multi-gpu system) would disable the use of the extension.
Well times have changed and actually presentation-time on wayland for
nvidia works now amazingly enough. For xorg, the extension still doesn't
work, but from user testing it does not seem to be harmful anymore. It
just does nothing. So we can remove the blacklist part and just only use
a whitelist. Like before, we only enable the extension for mesa drivers
by default so no practical change for anyone except multi-gpu systems
whom may have this enabled now but should not see any negative behavior
change.
Basically we only want to create the color surface if the compositor
supports parametric image descriptions and if the vo is dmabuf-wayland.
Instead of doing the weird dance of creating it in one spot and
destroying it later, just only make the wayland object when we actually
want it. It makes the logging less confusing as well.
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
we keep track of the current vo struct to flag for events that are
initiated async by various thread from different system notifications.
the problem here is the usage of that vo struct after uninit.
make accessing of that vo struct atomic and clear it on uninit, so it
can't be used afterwards by concurrent threads from system
notifications or events.
Fixes#15088
since commit 15c48f3 we were force to start drawing on the main queue
again. this has several unintended side effects due to the nature of the
main queue. in this case fullscreen event and shutdown event are
executed out of order and fullscreening is done after shutdown, leading
to accessing options that are already de-initialised.
just nil the window on shutdown and make it impossible to fullscreen
after shutdown.
Fixes#14810
The implementation is minimal since it already uses XIM for UTF-8 text
input. The only changes needed are small fixes: setting the IC focus and
correct the usage of window param for XFilterEvent, and IME will
"just work"...
...after setting 2 process-wide global values before VO creation:
LC_CTYPE and X locale modifiers. So this usage is currently limited to
libmpv clients which don't want to do their own IME processing.
locale strikes once again:
XIM input methods require them to be set before creating the XIM context to
work, even though they don't matter after the context is created. Both of
these values being process-wide global means that the only time to safely
set these values is before the process creates any thread.
In theory, mpv could set LC_CTYPE in the main when running standalone,
but locale being locale means something is always messed up. In this case,
setting LC_CTYPE changes "Character classification and case conversion"
behavior. While mpv uses its own ASCII-only is*() and to*() functions to
avoid some of the issues, it also uses strcasecmp() and POSIX regex which
behaviors are affected by LC_CTYPE.
In summary, to avoid unavoidable race conditions mpv won't do this in
standalone mode right now.
It's now libmpv users' responsibility to:
- set LC_CTYPE to a locale usable for XIM, such as a UTF-8 locale
- set X locale modifiers with XSetLocaleModifiers
- hope that all stars align if trying to switch locale back afterwards
On most setups, both of these can be empty strings, In this case, the usual
XMODIFIERS environment variable must be set to enable IME support.
(e.g. XMODIFIERS=@im=fcitx)
Uploading all available formats has proven to be problematic because
more unusual ones can crash the driver, even when no upload is
necessary. Check the upload only if needed to avoid issues with broken
drivers.
This also might speedup the init process.
Fixes: #14956Fixes: #15030
VO_WIN_FORCE_POS is set even if the position is not provided by the
user, so we have no choice but to always fit. We should do this
regardless, and if any issues occur in multi-monitor configurations,
they should be addressed separately.
Fixes: #15049
Fixes: e5159de811
VK_EXT_shader_object was added in 1.3.246, mpv currently requires
1.3.238. Debian stable is at 1.3.239.
Fixes build on Debian stable (Bookworm).
Fixes: #15041
Fixes: 2ac1d6db32
Bit of an edge case since image-lut requires the frames to be remapped
again so the normal redraw when paused doesn't work. Also we use
update_options in the VOCTRL here.
Kacper Michajłow
der richter
M Stoeckl
llyyr
nanahi
Dudemanguy
Niklas Haas
Rasmus Porsager
Mohammad AlSaleh
Julian Orth
Lynne