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.
This remembers and sets window-scale when exiting maximized state. Also
fixes not staying in maximized state when exiting fullscreen mode.
Fixes: #14126
this is already done in the updateSize method of the window.
also fixes an issue where the size wasn't properly changed, even though
the new and old size were different. the unfsContentFrame should have
been checked instead of the pixel representation of the same frame.
With the pieces set in place with the previous changes, we can implement
the desired behavior. The trick here is that we do want to force
centering the window when mpv first initially starts and the window size
is not known yet. This can be done by simply checking
x11->pseudo_mapped. The other change is to just look if we have the
VO_WIN_FORCE_POS flag and feed that to highlevel resize.
c4e8c36071 made any usage of --geometry
implicitly center the window on the screen after a resize even if the
user did not pass any x/y arguments to the option. At the time, this was
probably wanted since --geometry was primarily a startup option and
likely the window wouldn't be centered on x11 without moving
coordinates. Times have changed since then and we support full runtime
--geometry changes on all the relevant platforms but it comes with this
automatic window centering behavior (except on wayland of course hah).
It's better to make such window centering optional and user controllable
since it is entirely reasonable that someone wants --geometry=50% to
just resize and not move anything. It's already trivial for a person
that does want to move the window to just add their coordinates to the
--geometry command so there's no reason to continue to force this
behavior since it is less flexible.
Instead, move the window centering stuff out of m_geometry_apply into
vo_calc_window_geometry. We give the power to the caller to whether or
not to force centering the window here and all usage of the function is
updated to simply call it with false for now. Additionally,
--force-window-position being set will also center the window like
before. All that is left is for the windowing code to take advantage of
this. See subsequent commits.
There's really no reason to have all these extra variants. It's not like
this is public API. Collapse it all into one vo_calc_window_geometry
function and callers can simply just pass the appropriate parameters to
get the same behavior as before. I'm about to edit this function again
in a future commit and I really don't want to make a
vo_calc_window_geometry4 for this so let's clean it up.
The multi device part is mostly theoretical, but it turns out that
plasma does send multiple tranches to the same device so we have to take
that into account. And that means taking into account multiple devices
as well. In theory, a compositor should give us tranches for any device
that will work so as long as we find a match it should be OK. This is
still technically incomplete since mpv's core wouldn't react to a device
being hotplugged.
Both of these VOs draw buffers in software via wl_shm to an mp_image, so
they are affected by the internals of whatever mpv does for alignment.
When wlshm was originally written, mp_sws was aligning to 16 bytes and
thus it chose this value but it was hardcoded. vo_dmabuf_wayland later
blindly copied this value. e1157cb6e8
actually changed the internal value to 64 bytes. In theory, this doesn't
probably doesn't really matter since 16 should also work in most cases,
but we might as well stop using a magic number and be consistent.
Additionally, wl_shm did some funny alignments that no other software
output did. The reasoning was apparently due to warning messages from
ffmpeg while cropping*. This was left in at the time, but I'm not able
to reproduce any such warning messages on my end when I make this match
other software VOs. Go ahead and remove the MP_MAX business and align to
the fmt x/y like the other VOs do.
*: https://github.com/mpv-player/mpv/pull/6240#discussion_r227930233
4d09cde8f9 added this behavior and made
the format filtering more aggressive, but it's over correcting. The
misunderstanding on my part is that the problem was with modifiers not
with formats. There is hardware that do not have any valid modifiers
which means certain formats cannot possibly work correctly with
vo_dmabuf_wayland (broken colors etc.). Formats on the primary plane do
not require modifiers so if it happens to be a planar format, we can
accept it and possibly use mpv's autoconverter. If we do get a valid
format + modifier pair from the compositor, then we should always accept
it regardless if it is planar or not.
The old name is misleading. We do want these formats, but it is not
accurate to call them "gpu formats". Call it "planar" instead so it's
more obvious these come from drm primary planes.
This results in all image params not being restored even if only one is
unknown. In particular params->color.hdr isn't cleared, causing
overblown color for some samples.
It should be safe to restore even unknown values.
mp_image_params_guess_csp will handle that.
This reverts commit 3acd253e89.
This is probably fringe, but I encountered it on my machine. The
hwupload filter happily does conversions all on the GPU side if
possible. Makes sense. However, it turns out that there is a difference
between e.g.yuv420p -> vaapi[bgr0] and a vaapi[yuv420p] -> vaapi[bgr0].
The latter worked without any issues on my hardware, but the first
example fails. To remedy this, we need to also do hardware uploads
during probing against formats and track what actually works (i.e.
vaSurfaceExportHandle). This commit only implements it in vaapi since it
is the only known place where this edge case is relevant. But other
hardware decoding drivers could easily add support later if needed.
It's a bit roundabout, but we were doing this incorrectly before. The
format table alone isn't good enough because it is possible the the
compositor may advertise different formats for a specific device which
is a subset of the format table. What we need to do is add formats based
on the array in tranche_formats. Note that it is possible for the
compositor to send multiple tranches (was not able to simulate this but
it's allowed by the protocol). For mpv, we only care about the very
first one which is supposed to be the most preferred one. The compositor
can also send the entire chain of events (main device, format_table,
tranches, etc.) all over again. We handle this in the wayland code, but
handling this in mpv's core code isn't done. e.g. say a format in use
was suddenly no longer supported. We ideally should do a full reconfig
in this case, but that gets complicated and is pretty niche so save that
for another day. Multiple GPUs isn't taken into account either. We just
pick the first one. Not strictly correct, but close enough for us.
Fixes#14544.
The linux-dmabuf protocol gives us the main device being used. Using
that along with some drm code, we can get what drm formats are supported
by the GPU. This is pretty crude as we just check against the first
primary plane we find and hope for the best. Also the protocol can
technically update formats at any time (e.g. if the device changes). We
do update what gets stored in wl->gpu_formats but the next commit won't
make any attempt to address this hypothetical scenario. It's complicated
and this is better than nothing. In practice, this will only work
against one constant device during VO runtime. Additionally, we can add
this check to ra_compatible_format to filter out additional unsupported
formats.
Even Debian stable has them, so no need to keep compatible with ancient
versions.
Note that this does not change runtime version requirement for Vulkan.
Fixes: https://github.com/mpv-player/mpv-build/issues/234
On platforms where it is unstable/experimental, it is disabled behind
environmental variable, so safe to probe it there too.
Fixes usage of hwdec=yes with gpu-api=vulkan, where hwdec would be not
enabled. Position it after older and more stable variants. That means
the -copy variant of the other API will likely be prefered.
This allows Tab completing them in the console and zsh, and using cycle
scale.
jinc is also added to --tscale=help's output, while before it was
missing because validate_scaler_opt() skipped filter windows with the
same name as a filter kernel, but the jinc kernel was skipped with
--tscale because it is polar.
The comment was probably only ever true for x11, and it currently isn't
true anymore. X11 WSI used to return VK_SUBOPTIMAL_KHR in
vkQueuePresentKHR and vkAcquireNextImageKHR before, but as of
2b885b233f
it only returns VK_SUBOPTIMAL_KHR in vkAcquireNextImageKHR for
performance reasons. This makes it so that we don't have to tolerate
suboptimal swapchain configurations for the sake of smoother resizing.
On top of that, not recreating swapchain when it was suboptimal, it
also prevented mpv from being directly scanned out when fullscreened on
Wayland compositors. On Wayland, the preferred modifier from the wsi
may change depending on whether the window is fullscreened or not for
direct scan out. If mpv is fullscreened but not using modifiers that
can be directly scanned out, mpv will be receive VK_SUBOPTIMAL_KHR from
WSI and should recreate swapchain to use the right modifier with the
format mpv picked. mpv will always get the format it picks, WSI can't
give us a different format. This allows for recreating the swapchain
with modifiers that will allow mpv to be directly scanned out when the
window is fullscreened spanning an output on Wayland.
I checked X11 and Wayland myself to have no regressions when resizing,
and others have checked Windows and Mac to have no regressions.
With this, direct scanout with Vulkan on Wayland should just work.
You might also need https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31122
if your compositor enables explicit syncronization via
linux-drm-syncobj-v1.
Resizing in strictly the vertical direction has been broken forever on
wayland. It's because of how the keepaspect calculation always resized
with respect to the width. So if you moved the mouse strictly
vertically with no change left/right, the mpv window would never change
size since it just calculates with respect to the width that doesn't
change.
Fixing this is kind of weird and maybe someone should think of a better
algorithm for preserving aspect ratio (we just multiply by the gcd
basically), but whatever. You might naively try something like "resize
with respect to what direction changes the most" at first, but this
leads to very cludgy resizing since during a typical mouse dragging
motion, it will flip constantly from "resize w/ respect to the width"
and "resize w/ respect to the height". It "works" but it's really ugly
and not worth it.
The trick is to realize that we need to consider the resizing state as
one continuous motion, choose a direction initially, stick to it
throughout the entirety of the resize, and reset the relevant parameters
after we finish the resize. This ensures the direction never
unintuitively flips during a motion, but also allows for the strictly
vertical case to still work.
Might as well note it here in the commit, but mpv's resizing behavior
technically violates xdg-shell. For the resizing event, "[t]he window
geometry specified in the configure event is a maximum; the client
cannot resize beyond it." Well, we do obviously go beyond the maximum in
certain cases. For example consider resizing strictly horizontally. The
width value increases from the compositor but not the height. Since mpv
preserves aspect ratio by default, the height obviously must increase
which will go over the prescribed bounds by the compositor. This happens
before and after this commit, and I think everyone agrees is the desired
behavior. With this commit, now vertical resizing works which violates
xdg-shell in the same way. Before, it incidentally obeyed the protocol
since it did not resize at all, but let's presume users expect the
window to actually get bigger when they do a drag resize.
*: https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:resizing
