If p->colormatrix is 0 if not set by user, so it would always override
_orig parameters with Dolby Vision ones and restore that erroneously.
Fixes: e2365bfece
Clipboard contents are available as selection data offers under
Wayland. The offer can become invalid at any time, so request the
text format content immediately when an offer is received,
and cache the content for later use.
Instead of printing circles in show-text ${playlist}, ${chapter-list}
and ${edition-list}, introduce --osd-selected-color and
--osd-selected-outline-color to reduce clutter, make the selected item
easier to differentiate, and have visual consistency with select.lua.
The defaults are taken from the style of the selected item in the
console. These new options are also used there, replacing the hardcoded
styles. Due to being user-configurable, selected item styles are changed
to take priority over default item styles.
The default selected style is yellow and bold. The bold (hardcoded)
allows differentiating the selected item with color blindness. There is
also a separate --osd-selected-outline-color option defaulting to black,
since without it if the user changes --osd-outline-color yellow text
becomes unreadable without a black border. --osd-selected-back-color is
omitted for now.
Text and background colors are inverted for the selected item in the
terminal. This is hardcoded, adding an option is overkill.
A disadvantage of this commit is that if you run print-text ${playlist}
with a VO, the selected style ASS is printed to the terminal (but ASS
printed in the console is interpreted). This commit avoids printing the
reset ASS sequence for non-selected items to reduce clutter in this
case.
It turns out mpv doesn't tag at all when doing conversions, so we just
re-tag here and hope for the best. This should be improved, but there
are many different code paths when conversion can happen, so for now
revert to previous behavior.
Fixes: 4e5cc9cf1d
If we lose the current output for any reason (unplug, turns off, etc.)
and then later it comes back, mpv should always recalculate all the
scaling stuff. The optimization to avoid needless scaling calculations
didn't consider this case and would always exit since the scaling is the
same. So just check wl->current_output's existence as well.
Fixes#15361.
Whenever mpv window gains focus, a new data offer is sent for the
selection. However, mpv currently treats it the same as dnd data
offers, which results in wrong handling. One bug which results from
this is when focus follow mouse is enabled, dropping the dnd file
results in the window being focused and selection offer being sent,
freeing the existing dnd offer. This results in dnd being broken
on at least GTK3.
Fix this by separating selection and dnd offer handling. Since there
is no way to know whether an offer introduced by
data_device_handle_data_offer is a selection or dnd offer, make it
pending, and move them once the identity is confirmed.
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>
Kacper Michajłow