| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager
Hints) require that the string is UTF-8*. mpv was not doing this and
thus violating the spec. Just sanitize the title for these two atoms.
Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so
those atoms are left the same. Fixes #8812.
*: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
|
|
|
|
|
|
|
| |
The xdg-shell protocol requires that the toplevel title is UTF-8*. Go
ahead and leverage existing mpv tools to sanitize the title. Fixes #9694
*: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/0aaf12157ede8fdf6eda49963da313bd1a7d930f/stable/xdg-shell/xdg-shell.xml#L638
|
|
|
|
|
|
|
|
|
| |
Apparently mutter can send us 0x0 resizes* for whatever reason. Probably
there's some interal reason why this occurs, but for us trying to resize
to 0x0 is obviously terrible and results in all kinds of brokenness.
Just ignore any 0 values. Fixes #9748.
*: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
|
|
|
|
|
| |
Can be used conditionally (via #ifdef HOOKED_gather) to use
textureGather in custom shaders.
|
|
|
|
|
|
|
|
|
| |
The only way to fix the channel order here is to create the texture with
bgra format. Incidentally, there used to be a way to set the component
map for overlays directly, but no more. Shouldn't matter since
everything supports bgra8 anyways, though.
Fixes #9699
|
|
|
|
|
| |
This was a misnomer, the actual channel order is IMGFMT_BGRA (as the
comment explicitly point out). Rename the enum for consistency.
|
| |
|
|
|
|
|
|
|
|
|
| |
These got added upstream a while ago. Need to be added to the mapping
helpers.
It might be time to think about bumping the minimum dependency here.
Reported-by: Uoti Urpala <uau@glyph.nonexistent.invalid>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Useful to strip dolbyvision from the output, in cases where the user
does not want it applied. Doing this as a video filter gives users the
abiilty to easily toggle this stripping at runtime in a way that
properly propagates to any (potentially stateful) VO.
It also thematically fits the rest of the options in vf_format, which
are similarly concerned with modifying the video image parameters.
|
|
|
|
| |
Co-authored-by: Niklas Haas <git@haasn.dev>
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of `xkb_keymap_new_from_string`. The protocol does not require
the keymap to be null terminated and if the size of the keymap is a
multiple of the page size, using `_from_string` could lead to problems.
Some compositors include a null byte and even include the null byte in
`size`. Therefore we have to use `strnlen` to find the real length of
the string. Note that `_from_string` internally uses `strlen` and then
calls `_from_buffer`.
|
|
|
|
|
|
|
|
|
|
| |
While mpv uses version 1 of the `wl_seat` protocol and `MAP_PRIVATE` is
only required from version 7 on, using `MAP_PRIVATE` allows us to be
compatible with compositors that have only been tested with newer
applications.
Since the keymap is not modified after `mmap`, using `MAP_SHARED` has no
advantage over `MAP_PRIVATE`.
|
|
|
|
|
|
|
|
|
|
|
| |
This merges the old desaturation control options into a single
enumeration, with the goal of both simplifying how these options work
and also making this list more extensible (including, notably, new
options only supported by vo_gpu_next).
For the hybrid option, I decided to port the (slightly tweaked) values
from libplacebo's pre-refactor defaults, rather than the old values we
had in mpv, to more visually match the look of the vo_gpu_next hybrid.
|
|
|
|
|
|
|
| |
Merge --gamut-clipping and --gamut-warning into a single option,
--gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs
and allowing us to easily extend this option as new modes are added in
the future.
|
|
|
|
|
| |
Properly forward the HDR metadata from the mpi to the equivalent (new)
fields in pl_color_space. Used by the new tone mapping code.
|
|
|
|
|
|
|
| |
This was significantly refactored upstream. Switch to new APIs and add
new tone mapping curves and options.
cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
|
|
|
|
|
|
|
| |
image2D is only defined from GLSL ES 3.1 onwards, so those statements
broke GLES 2.0. Move the qualifier to a place that is only reached with
the right version requirements.
fixes commit 584ab29c88d6c5ffa03666bffbbc93e4f0740f67
|
| |
|
|
|
|
| |
This is in nits, so it needs to be converted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commits 04018c306196888861775b248a8596ae494f122b
cd7a7a1de8d8bffa05170befef25b251711c994a introduced behavior that
updated window geometry during wayland events (specifically surface and
output). This is good but they also are too aggressive with
automatically resizing. For example, if a window is manually resized by
the user and then dragged to a different monitor with different geometry
than the initial monitor, mpv will automatically resize itself to the
window's resolution. The initial thought behind this logic was for
autofit to automatically readjust itself on a new monitor, but doing
that breaks other common use cases. An attempt could be made to
distinguish between autofit and a manual resize but that introduces a
lot of complexity for an edge case. It's better to simply not change the
window geometry here. Internal values are recalculated and scaled of
course, but wl->window_size and wl->geometry should not change.
|
|
|
|
|
|
|
|
|
|
| |
We've been assuming that maximum number of compute group threads is
never less than the 1024 defined by the desktop GL spec. Given that we
haven't had working compute shaders for GLES and I guess the Vulkan
spec defines at least as high a value, we've gotten away with it so
far.
But we should really look the value up and respect it.
|
|
|
|
|
|
| |
This is only needed on Android and supposed to handle a context
resize without reconfiguring the image parameters. reconfig()
already does exactly this so plug it in there.
|
|
|
|
|
|
| |
fixes #9249 (JPEG orientation support) with ffmpeg commit [0].
[0] https://github.com/FFmpeg/FFmpeg/commit/e93c9986027d17917c3b4f533b28ee4a2ce7cd4c
|
| |
|
|
|
|
|
|
|
|
|
| |
It's supposed to work with GLES >= 3.1 but we had all sorts of bad
assumptions in our version handling, and then our compute shaders
turn out not to be GLSL-ES compliant.
This change contains some necessary, but insufficient, tweaks to the
shaders. Perhaps we'll make it actually work some day.
|
|
|
|
|
|
|
|
| |
Some of the extension declarations did not include the ES version where
they became core functionality, and in some of these cases, there was
never actually an ES extension - it first appeared in core. We also had
a number of buggy version checks where ES versions were compared
against required desktop GL versions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nvidia follow the OpenGL spec very strictly, with two particular
consequences:
* They will give you the exact context version that you ask for,
rather than the highest possible version that meets your request.
* They will hide extensions that the specs say require a higher
version than you request, even if it's technically possible to
provide the extension at lower versions.
In our case, we really want a variety of extensions, particularly
compute shaders that are only available in 4.2 or higher. That means
that we must explicitly include a high enough version in our list of
versions to check for us to be able to get a 'good' enough context.
As for which version? We restore the 4.4 version that we had in the
old version selection logic. This is the highest version we ever asked
for, and we have separate logic that clamps the GLSL version to 4.4,
so anything newer wouldn't make a difference.
|
|
|
|
| |
This call was completely wrong.
|
|
|
|
|
|
|
|
|
| |
`plane_data_from_imgfmt` doesn't zero-initialize the struct, so this
contained invalid values for e.g. `row_stride`, causing formats to
*randomly* fail. (Especially any formats with specific alignment
requirements)
Might fix #9424 and #9425.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a workaround for nvidia proprietary drivers. The authors of
those drivers interpret the spec such that eglMakeCurrent will not
reconfigure the read and draw buffers. Thus windows wont display
anything drawn by opengl. nvidia authors refer to
https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
specifically Issues 2/3 which reference eglMakeCurrent.
On mesa this is a non-issue and the read/draw targets are assigned with
eglMakeCurrent.
The context must be made current in order to query OpenGL strings. An
earlier proposal to create the wayland window surface similarly to X11
during init was deemed inappropriate so instead we manually set the
targets once we have created a window surface.
|
|
|
|
|
| |
This function is provided by a different extension on OpenGL ES so we
add a separate gl_functions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somewhat annoying but still relatively straightforward. There are
several ways to approach this, but I settled on reusing the pl_queue as
a cheap way to get access to the currently mapped frame. This saves us
from having to process `vo_frame` at all, and also avoids any overhead
from re-uploading the same frame twice.
(However maybe there's some circumstance in which `vo_frame` needs to be
queried/updated first, to get a screenshot of the correct frame? I'm not
sure.)
I also had the option of going with either pl_render_image() on the
extract pl_frame, or just calling pl_render_image_mix directly on it. I
went for the latter, because in the optimal case, this allows the
rendered frame to be directly retrieved from the cache, actually
entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s
during playback essentially free. (Except for the download cost,
obviously)
It would be even neater if we could make this VOCTRL asynchronous and
thereby leverage libplacebo's asynchronous download capabilities. But oh
well. That will have to wait for a sufficiently rainy day.
Closes #9388
|
|
|
|
| |
In preparation of VOCTRL_SCREENSHOT support
|
|
|
|
|
|
| |
As noticed in #9526, apparently there's some case in which DR buffers
get corrupted. Add an explicit sentinel check to try and figure out
which cases these are.
|
|
|
|
| |
Suggested by haasn
|
|
|
|
|
|
|
|
|
|
|
| |
This commit sucks bad, but everything else is worse is other ways.
Basically, the current vblank waiting time in the vo_wayland_wait_frame
function (calculated very carefully using presentation statistics) is
randomly too short. Some compositors are quite variable when they
actually return callback so our timeout expires too quickly and throws
everything off. The fix? Add an arbitrary 5% to the vblank value and
pray that nothing gets off that much. Why did they have to make
swapinterval 1/fifo mode indefinitely block? Fixes #9504.
|
|
|
|
|
|
|
| |
Better to avoid any wonky calculations on startup with garbage values.
The others end up being derived from last_ust/last_msc. refresh_interval
is referenced exactly once and could, in theory, result in some terribly
erroneous vblank time.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A read can be prepared on the wayland display FD that is never actually
read. This occurs when events are triggered on other FDs in the fd set.
This change cancels a prepared read if poll reported no events for it.
This fixes some hangs due to how nvidia's EGL implementation polls on
the wayland fd unlike mesa implementations. It is based on nvidia's
proposed fix for qt's similar message pump in
https://codereview.qt-project.org/c/qt/qtwayland/+/373473
Signed-off-by: Kurt Kartaltepe <kkartaltepe@gmail.com>
|
|
|
|
|
| |
If the EGL extension is present, pass the modifiers for each plane
to the EGL driver.
|
|
|
|
|
| |
Wrapping the context is pretty straightforward. This is only complicated
by needing to account for the upside-down framebuffer in a few places.
|
|
|
|
|
|
| |
This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code
when additional backends are added in the near future.
Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
|
|
|
|
|
|
| |
This case was added in 662c793a557925319493297de8c941a636f18d73
for use in vo_gpu_next as a visibility test before rendering a frame.
The OpenGL context doesn't have this so it just returns true.
|
|
|
|
| |
Fixes 2b2442ee67913221e5c87cbc06010671e1b41c15
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed when the color system is not explicitly tagged, but
instead needs to be inferred by the VO.
Note that there exists the function mp_image_params_guess_csp for this
sort of stuff, but it contains a lot of baggage that I don't want to
replicate, in order to move as much of this logic into pl_renderer as
possible, and therefore also give it the best chance of knowing what
shortcuts it can and can't take.
Fixes the other half of https://github.com/mpv-player/mpv/issues/9499
|
|
|
|
|
|
|
|
|
|
| |
Adding vsync_offset to the pts in pl_queue_update actually messes up
frame timings if one isn't using interpolation. The easiest way to see
this is to have the monitor's refresh rate at an integer multiple of a
video during a panning shot (classic case). There will be very visible
judder/stutter in this case that does not happen in vo_gpu. The cause of
this is the addition of the extra vsync_offset. Just match the semantics
of vo_gpu where this is only used when interpolating.
|
|
|
|
|
|
| |
Similar to ff0864d5f07d31c808014dbf1791ed3ec14644a8
Fixes #9484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This possibility actually existed for years. The wayland protocol is
asynchronous and there's no restriction on when a compositor can send a
surface enter event. In mpv's case, the surface enter event is used to
set some vital things regarded geometry/scaling etc. However, this
implictly assumes that wl->current_output is actually initialized. The
vast majority of the time, vo_wayland_reconfig will happen first which
is where wl->current_output is, and should, be created. There's no
rule/law that the ordering of events will always occur in this order.
Plasma with certain auto-profile conditions can send the surface enter
event before mpv does its initial reconfig. That segfaults of course.
Just add a check to make sure we have wl->current_output here and return
if we don't. This assumes that the compositor will send us another
surface enterance event when mpv actually does the initial surface
commit and roundtrip request later. Wayland logs indicate this does
happen. Fixes #9492.
|
|
|
|
|
|
| |
It was never implemented before but it's trivial. As an aside, touch
events currently don't support modifiers either (is this a thing?). Well
if someone complains that can be done later. Fixes #9490.
|
|
|
|
|
|
|
| |
Even when not display synced. Prevents redraw overhead for refreshes
while paused.
Also make the logic slightly clearer to follow (since it's inverted).
|
|
|
|
|
| |
Fix typo in the warning to avoid ewa_lanczossharp because
it might be removed in the future.
|
|
|
|
| |
Matches what `pl_log_create` does as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This almost perfectly recreates the semantics of --vo=gpu, i.e.:
- still frames are never interpolated
- non-repeated frames bypass single frame cache
The only difference is that libplacebo doesn't do a cache/blit on the
full output image, but rather it re-runs the last rendering step. This
has some advantages and some drawbacks. The most notable advantage is
that it also allows re-using the image contents when the only thing that
changes is the OSD (whereas `--vo=gpu` would force a full re-render for
that). The most notable drawback is that it also implies going through
the dithering and output LUT logic on redraws. All in all, I think this
is a pretty good trade-off in favor of `--vo=gpu-next`.
Fully fixes the last remaining performance difference in #9430.
|
|
|
|
| |
Closes #9454
|
|
|
|
|
|
|
| |
GLX_CONTEXT_PROFILE_MASK_ARB and related constants are provided by
GLX_ARB_create_context_profile but the check was for _create_context.
The former implies the latter (which we also need) so just replace
the checked extension.
|
|
|
|
| |
Again no functional difference, just uses better APIs when they're available.
|
|
|
|
| |
This does what 3a10210c568f9c7d969ca6c4da2377c55fbf30f3 was supposed to, but better.
|
|
|
|
|
|
| |
It abstracts EGL 1.5, extension checks and other inconsistencies away.
This can be used in context code as the (preferred) alternative to
eglCreateWindowSurface().
|
|
|
|
|
|
| |
Using a simple substring match for extension checks is considered bad practice
because it's incorrect when one extension is a prefix of another's name.
This will almost surely not make a difference in practice but do it for correctness anyway.
|
|
|
|
|
|
| |
Although there are no known problems with this, using the helper should
be more portable. It will also prefer EGL 1.5's eglGetPlatformDisplay
over eglGetPlatformDisplayEXT if available.
|
|