| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used.
Resolves: #9641
|
|
|
|
|
|
| |
It's possible for systems to have multiple cards, and the first capable
card to not have a connected output. Skip such cards and continue
iterating until we find one with a connected output.
|
|
|
|
|
|
|
| |
Without doing this, --fs --fs-screen=1 wouldn't actually end up on the
desired screen since the sizehint was never sent. Also check the
screen-name variants for an empty string as well so the option can
properly "undo" itself (not sure if this has any practical effect).
|
|
|
|
|
|
|
|
|
|
|
| |
mpv mixes xinerama and randr usage together which gets kind of
confusing and is also pretty stupid. Xinerama is completely unneccesary
today since randr can do everything it can do and much more. Remove it.
This reworks a lot of the window/geometry handling stuff to be centered
completely around xrandr_display plus some other tweaks to the geometry
handling. An important concept is that current_icc_screen is changed
into current_screen and used more generously since it is useful for
things besides just icc profiles.
|
|
|
|
|
|
| |
There really is no reason to not just hard require randr 1.4. xorg added
1.4 support in 2012 and someone somehow using an xorg server older than
that today surely has several other problems.
|
|
|
|
|
|
|
| |
If we failed to create a gbm surface, we would call drm_egl_uninit
to free up any state we had allocated. However, we would segfault if we
tried to cleanup properties there were never initialized. Null checks
have been added to guard against this.
|
|
|
|
|
|
|
|
| |
Before d208284, this was implicitly reset back to 0 at the start of
every update_options(). But we no longer explicitly reset par->params,
so we need to do it manually here for the hooks.
Fixes: https://github.com/mpv-player/mpv/issues/12203
|
|
|
|
|
|
|
| |
Undefined behavior (bad initializer). Somehow didn't trigger a warning
on my end...
Fixes: a8192eda6cfc909fc9f5f62e36523b53c0300eff
|
|
|
|
| |
To help test not-yet-exposed options, and for debugging purposes.
|
|
|
|
| |
This is already set by map_scaler, just disable it if unwanted.
|
|
|
|
| |
No need to override this so late in the general (non-screenshot) code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With a backwards compatibility shim for older versions of libplacebo in
which we simply define the relevant subset of this struct ourselves and
initialize it to known-good values, to be able to continue using our
options assigning code.
It's worth pointing out that our use of scalers deviates from how
pl_options was intended to be used, as a consequence of backwards
compatibility with pre-308 versions of libplacebo. But this should work
fine in practice, since we don't care about serializing these custom
scalers correctly. Users can still override them using the built-in
pl_options scalers when loading custom scalers via --libplacebo-options.
(To be added in the next commit)
|
|
|
|
|
|
| |
This was already correctly freed when acquiring a new profile, but never
freed on uninit. Fix by reparenting the profile onto `p`, which is what
vo_gpu also does.
|
|
|
|
|
| |
This header is installed unconditionally starting with libplacebo
v4.208.0, so we are safe to remove the check.
|
|
|
|
|
| |
Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is
requested.
|
| |
|
| |
|
|
|
|
| |
v6.292 implied by minimum dependency.
|
|
|
|
| |
Now implied by the minimum libplacebo version.
|
|
|
|
| |
LIBPLACEBO_NEXT is now implied by libplacebo being available
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This completely disables all smoothing. Despite what the manual claims,
a decay rate of 1.0 does *not*.
It's worth pointing out that this depends on the following commit to
work properly in --vo=gpu-next, but I don't think working around such a
minor detail is worth the trouble, considering people building nightly
mpv are probably also building nightly libplacebo it should just work
(tm).
See-Also: https://github.com/haasn/libplacebo/commit/1c464baaf4c6228dcfac87f19db1dafc22e328c8
See-Also: https://github.com/haasn/libplacebo/commit/83af2d4ebd5086a56f7b1a2f86628ada3612ee7c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libplacebo doesn't like it when the queue_params PTS is less than the
actual PTS of the frame for the first frame and skips mixing it during
interpolation. This can happen if you seek while paused because mpv will
always keep the vsync_offset value as if it was still playing. So in
some cases, this can be a negative value and thus the PTS will end up
decreasing and libplacebo interprets this frame as a first frame. This
skips mixing the frame and thus you get a black screen. To fix this
this, just realize that vsync timings are completely meaninglessly in
while paused. If you are not actively pushing frames, there's no reason
to care about vsync_offset. So just clear it and make it zero when the
VO's internal state is paused and we're trying to render a frame. Makes
libplacebo happy and fixes #11958.
|
|
|
|
|
|
|
| |
It was actually always wrong, and no one ever noticed. This currently
returns the size of the entire display area and not one actual monitor.
Fix this by calling get_monitor_info and then doing the appropriate
subtractions. Checked by @CrendKing and fixes #12172.
|
|
|
|
|
|
|
|
| |
There was no known problem with this, but according to the wayland
spec*, "After this event client must assume that no keys are
pressed...", so go ahead and do that.
*: https://gitlab.freedesktop.org/wayland/wayland/-/blob/72da004b3eed19a94265d564f1fa59276ceb4340/protocol/wayland.xml#L2449
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced by 1f8013ff3fddd788a517656e09f5ce5d7efd928d. We try to save
the mpkey so it can be used in the modifier event that comes next if
appropriate and also clear it when needed. The problem is that the
condition for clearing is too strict and things like mismatched cases
and so on can make mpkey on the corresponding key release event not
match the saved mpkey even though in reality they were the same key.
Loosen the check by simply always clearing the saved mpkey as long as
there was some key found and the state is up. We don't handle multiple
keys at the same time anyways (they're interpreted in a sequence), so it
should be hopefully OK.
|
|
|
|
|
|
|
|
|
| |
During initialization, the mpv window was not available and wayland
simply just reported nothing. But this can be a nuisance and there are
cases where having a values is better than nothing (vapoursynth). So if
current->output isn't available yet, fallback to find_output instead.
This is influenced by what is set by options like --screen and
--screen-name, but we'll consider that a feature not a bug.
|
|
|
|
|
|
|
|
|
|
| |
This deliberately wasn't being done when mpv was embedded
(fbccddb48b4c71c18300b092ef7a3860be2a659a). There are some applications
that would benefit from mpv setting a title since they don't do so
themselves (such as tabbed), but at the same time some others would
probably rather not have this behavior (like smplayer). Add an option
that allows an embedded mpv to set the title if the user wishes.
Fixes #11528.
|
|
|
|
| |
similar to free(), XFree() is a no-op if argument is NULL
|
|
|
|
|
|
|
|
| |
XDestroyWindow() is called immediately after, which also unmaps window
if needed. according to the manpage:
> If the window specified by the w argument is mapped, it is unmapped
> automatically.
|
|
|
|
|
|
|
|
|
|
|
| |
983e8f0100b98bd8aed48e5fe86dd5682174b04e resulted in the correct
dimensions, but it was not actually right because vo_gpu_next still had
the src and dst rects the same. This just needs to work like how vo_gpu
does where the src is the image params and the dst is desired output. So
basically, just copy that code over here. Fixes #12108 and as a bonus,
overriding the aspect ratio now results in correct screenshots
(previously didn't work at now and then with the above commit it had
correct dimensions but still incorrect output).
|
|
|
|
|
|
| |
Using the width and height params directly doesn't actually work if PAR
is something other than 1. Instead, use mp_image_params_get_dsize and
calculate the correct dimensions which matches the vo_gpu behavior.
|
|
|
|
| |
Closes: https://github.com/mpv-player/mpv/issues/12093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1 is not enough to prevent PL_QUEUE_MORE, because the pl_queue is
designed to always know the next frame (in addition to the current).
Before haasn/libplacebo@112bb886, this was was (wrongly) silently
omitted by the pl_queue code, but that fix exposed this.
While it's technically API misuse on mpv side, due to the mpv vo code
having its own internal queueing and timing control, it shouldn't
actually make any difference in practice (and likely, the error message
showing up is the only meaningful bug here - the issue is entirely
cosmetic).
Fixes: https://github.com/mpv-player/mpv/issues/12101
|
|
|
|
|
|
|
|
|
|
| |
Configuration of filter parameters was moved from pl_filter_function (of
which the user had to make a copy) to pl_filter_config, with the
pl_filter_function remaining immutable.
Implement this new logic in a way that can reasonably exist side-by-side
with the old configuration API. Once we drop support for PL_API_VER
below 303, we can drastically simplify this code.
|
|
|
|
|
|
|
| |
The win32 code already updates itself on dpi changes. However, it never
signalled mpv's core when this happened which meant that the
display-hidpi-scale property never changed. Simply send the
VO_EVENT_DPI event when appropriate. Fixes #12081.
|
|
|
|
|
|
|
|
|
| |
The manual currently says that if dscale is unset, --scale will be
applied. However, this only works at init time. If you change the dscale
filter to be empty later, vo_gpu will segfault and vo_gpu_next will
throw an error and refuse the changes. That's because when the option is
unset at runtime, the value becomes "" not NULL and the vo's never
accounted for this. Fixes #12031.
|
| |
|
| |
|
|
|
|
|
| |
Debian 12 is out, with 2.4.114, and Ubuntu 22.04 has 2.4.110, this
#ifdef is no longer needed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is yet another unfortunate side effect of the width % SLICE_W == 0
special case. While looping through these rectangles, the rc->x1 value
on the final loop can be greater than the actual total width. This will
cause a buffer overflow if using the mp_draw_sub_overlay API. 2 of the
current VOs that use that work around it by adjusting the values
returned, but the better fix is to correct what's actually given in the
rectangles so you can safely use the values. As for the fix, it's simply
ensuring that rc->x1 doesn't extend beyond p->w with a MPCLAMP.
Previously, the code would always naively add SLICE_W (256) to rc->x0
which would easily extend past the actual width in many cases. The
adjustments in vo_vaapi and vo_dmabuf_wayland are dropped and in theory
vo_direct3d should work now since we can just trust the values given to
us in the rectangles. How nice.
|
|
|
|
|
|
|
| |
This code failed to handle the case of the swapchain submission being
skipped because the window was invisible.
Fixes: f9dc695b580c394bf4f9833d36e91b7fcbe009ea
|
|
|
|
| |
Presents frames at the correct time when DS is disabled.
|
|
|
|
|
|
|
|
|
| |
In 1f8013ff3fddd788a517656e09f5ce5d7efd928d, I mistakenly thought this
was only used for modifier presses way back in the commit it was
introduced in, but it actually also handles non-english keys/letters.
Instead of returning early, we should try xkb_keysym_to_utf8 first and
then return if that doesn't do anything so the modifier can then be
handled in the appropriate event. Fixes #12009.
|
|
|
|
|
|
| |
This has always been a pet peeve of mine and in fact I named the option
in meson "egl-wayland" with the intention of finally doing this. We call
everything that's egl "egl-foo" internally except for wayland.
|
|
|
|
|
|
|
|
| |
We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next
for this release, since this is the what most Linux distributions are shipping.
The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not
likely to ship the newest libplacebo release soon.
This reverts commit b73d96776cfee61f88bf60b27315baab32a2115d.
|
|
|
|
|
|
|
|
|
| |
Since this works by mpctx giving us a dummy image, we can be reasonably
be confident that when we receive a matching imgfmt with no underlying
hw_subfmt that this is simply force window from the player. Just allow
this to go through the usual wayland logic and skip the hwdec checking.
When we get the real image later, it will still error out on the
compositors that don't have proper support.
|
|
|
| |
Commit e50db42 changed how hwdec interop works. Adjust vo_vaapi accordingly by setting the appropriate image format.
|
|
|
|
|
|
| |
When video width is not a multiple of slice size, the last slice will overflow. Fix this by adjusting the width of the last slice to fit within the video.
Fixes issue #10436
|
|
|
|
|
| |
With the generic screenshot window implemented, this is no longer
needed since vo_drm already uses software scaling.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv has historically always treated the various tiled states in
xdg-shell as maximized (probably because it was easier). Well it turns
out that there are some tiling compositors (hyprland) that allow tiled
windows to maximize themselves. This can lead to some scenarios where
mpv ends up doing a maximize on hyprland which actually works since it's
not a no-op like on sway. Fix this by separating out the tiled state
from maximize. It works mostly the same, but the main difference is that
there's no request to tile yourself like there is with maximize. Should
fix #11954.
|
|
|
|
|
|
|
| |
There's a lot of checks that are along the lines of !maximized &&
!minimized or vice versa. Make a locked_size boolean and store the
value of this in here to avoid writing long lines since the next commit
will add yet another condition to this.
|
|
|
|
| |
New upstream feature. Disabled by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't know why we've been doing this wrong for so long or how I didn't
notice until now. Wayland specifically has an event for handling
modifiers. We even named it "keyboard_handle_modifiers" in the code.
What we should do is just get the modifier and save it after the xkb
state is updated. Then later if the user does something else (press
another key or clicks the mouse button), the saved modifier key is
applied. If you let go of the modifier at any point, the xkb will just
update its state again and we save a 0 again here (i.e. no modifier).
There is one bit of an edge case however. If a key is pressed BEFORE the
modifier, then we have to handle the mp_input_put_key in the modifier
event instead since the ordering is not guarenteed. What we do here is
keep track of the mpkey as well as the mpmod. However if we are unable
to find a matching mpkey and the key state is pressed down, assume it's
a modifery key that was pressed and don't update mpkey. That way
whenever the modifier event does happen, it can correctly handle this
and we know that the keys must be pressed down if we end up there in the
code path.
As another fun historical note, the xkb_keysym_to_utf8 line was actually
written by wm4 himself in 460ef9c7a4bd2527f7f17eb8c95eeff3b67455f8
nearly 10 years ago. As the commit shows, it was clearly intended to
handle modifiers (if lookupkey finds nothing, then try to find a mod
instead). Of course, this is extremely dated and wayland hasn't worked
like that in ages. This branch never actually did anything, and thus
we'll remove it here along with modifier lookup changes.
This solves bizarre issues with modifiers not working with random keys
while working fine with others (don't ask me why). Fixes #10286 and
fixes #11945.
|
|
|
|
| |
For better control over target display levels.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
828dd65ef84b4d8e95e70752b9eb0833909d1d23 started this and put it in the
most common place, but any resize mpv is doing should be accompanied by
that function call to correctly inform the compositor of the window
bounds. Since we also have to set VO_EVENT_RESIZE at the same time, it
makes sense to just put these in the same function. A slight thing to
note is that xdg_surface_set_window_geometry uses surface local
coordinates which means they are divided by the wl->scaling factor. If
possible, we should use surface local coordinates directly if available
(like in the toplevel config) to avoid potential rounding errors.
Otherwise, just calculate it out. The linked commit actually broke
some weston resizes in weird ways (window disappearing or completely
freezing). Don't ask me why and I didn't attempt to find out why either,
but with this it all appears to work normally again (the other
compositors don't appear to be any different, and they shouldn't be), so
we'll go with this since it fixes soemthing and it also is more
conceptually correct.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was never implemented so in cases where the compositor didn't have
support for the underlying format, the window would just be black and
quite unhelpful. Well it turns out that fixing this is actually really
easy because mpv has reconfig2 which returns the entire mp_image on
every reconfig. We can just use that mp_image to try and obtain the
format and modifier pair and then use that to check against what we know
the compositor supports. If there are any problems, error out
gracefully. Some code duplication with the vaapi/drmprime importers, but
it's probably better to keep these separate. Fixes #11198 and fixes #11664
|
|
| |