| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The docs specify that the +-X+-Y geometry values position the content.
This used to work correctly but got broken at 8fb4fd9a .
Geometry size is unaffected - this only concerns position.
Commit 8fb4fd9a made it center the window rather than the content by
taking the borders into account during positioning, but forgot to make
an exception when a position is specified explicitly.
This commit adds this exception, and now if a specific position is
requested then the borders are ignored, and the content is positioned
correctly.
|
|
|
|
|
|
|
|
|
|
|
|
| |
a02901cae77c86fb9de997a418296d1fc0e3eada changed how mpv was handling
wl_surface_set_buffer_scale. It's correct in that constantly setting the
surface scale on every resize (which mpv was previously doing) is
unneccessary and not right. However, it introduced a slight regression
if someone moved a surface to a new monitor with the same resolution but
a different scale. It did not trigger a resize and thus the video would
have incorrect dimensions. A later refactor changed how things looked
inside here, but this regression wasn't fixed. A resize should always be
triggered if the scale changes in this surface event. Fixes #9426.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mouse button event codes above `BTN_EXTRA` (the ones currently defined
in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`)
are mapped to `MP_MBTN9` and up. (Reminder that due to historical
reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely
misleading; the real forward and back buttons are `BTN_SIDE` and
`BTN_EXTRA` and are already mapped correctly by mpv.)
This functionality is analogous to what the X11 backend supports in
`video/out/x11_common.c` and what the Cocoa backend supports in
`video/out/cocoa/events_view.m`.
|
|
|
|
|
|
|
|
|
|
|
| |
According to the xdg-shell protocol spec, a 0x0 size from the compositor
means that "the client should decide its own window dimension". We were
not doing this correctly. What should happen is that mpv should simply
reuse the old window size if it is not maximized or fullscreened. This
should work on all (reasonably recent) versions of mutter and an
compositor that follows the spec.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So actually according to the xdg-shell spec, a 0x0 resize is meant to
indicate that "the client should decide its own window dimension".
Previously, this just accidentally worked. In mutter 41.3, they changed
how 0x0 resizes were sent and what actually happened was that mpv tried
to resize itself to 0x0. This was obviously broken, so the reverted
commit naively just ignored 0x0. It actually seemed to work, but it
ended up breaking older versions of mutter. It's also not exactly the
correct fix so it deserves a revert.
This reverts commit d16defac27fcfe3e5fc43af6e42c2e590988cd3d.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|