| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
It makes more sense as an option at this point. Also libdrm is not
optional at all. You have to get a drm format and modifier for this to
even work (the VO will just fail without DRM). Just hard require it and
remove the guards. vaapi can remain optional.
|
|
|
|
|
|
|
|
|
| |
mpv has never used this because we never really seemed to need it, but
it actually has a purpose. This informs the compositor of the actual
dimensions of the mpv window and avoids errors with sizes not matching
(particularly with weston). It's a better way to fix the "maximizing
causing an error on weston" issue since it also works for dmabuf-wayland
(which always had this problem).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original reason for this commit was to prevent a compositor error on
weston when going into the maximized state. The configured dimensions of
mpv didn't match its actual size and Weston is super strict about this
so it threw a compositor error which is fatal. It only happened in
opengl and this seemed like an OK workaround, so I went with this.
However, there's actually a far easier way to solve this problem and we
don't need this anymore. This has the benefit of avoiding a harmless
warning message that appears with gpu-next on opengl. The next commit is
the proper solution. Closes #10324.
This reverts commit 661b5542de21d46d4d7c4693e564f4eec0526812.
|
|
|
|
| |
*sigh*
|
|
|
|
|
|
|
|
|
| |
The implementation was copied from vo_gpu/vo_gpu_next but fundamentally
it doesn't make sense for this VO. Hardware decoding is not optional in
vo_dmabuf_wayland. We should be sure to request and load all supported
formats in the preinit and fail if there are any problems. There should
be no functional change from before, but it's more conceptually correct
this way.
|
|
|
|
| |
Fixes a segfault with --force-window=immediate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds osd support via shm buffers using a similar approach that the
normal buffers do, but it differs in a few key areas. One thing to note
is that sway and weston actually handle this extremely differently which
required all the abstractions here. In particular, weston does not cope
well with destroying the wl_buffer from shm outside of the release
handler at all (i.e. it segfaults). The workaround here is to simply
attach a NULL to the osd surface and do a surface commit before we
destroy the buffers. This is reasonable enough and seems to work well
although it's pretty weird. Sway is more straightforward although it
actually releases the osd buffer when the window goes out of sight.
Also, I found that it doesn't always release every buffer before you
close it unlike weston seems to do which is part of the reason all this
bookkeeping is required. I don't know if there's any other compositor
out there that can possibly handle vo_dmabuf_wayland right now, but
suffering through these two is good enough for now I think.
|
|
|
|
|
|
| |
Otherwise, we could fail and skip to uninit without initalizing this
which then will segfault because the list is null and accessed while
trying to destroy buffers.
|
|
|
|
|
|
| |
It's entirely pointless. Not having viewport is already a fatal error
for this VO as it cannot possibly work without that protocol. Just drop
all these redundant if's.
|
|
|
|
| |
Fixes crash when compositors advertise xdg_toplevel version >= 5
|
|
|
|
|
|
|
| |
mpv already guesses when the window is hidden so plugging in a proper
event that actually tells us this is really trivial. Note that there's
some redundancy with setting wl->hidden in a few spots, but nothing can
really be done about that as long as the crappy hack is still in place.
|
|
|
|
|
|
| |
This protocol no longer requires us to draw a separate cursor surface
and all of that horrible stuff. We can just ask the compositor for the
default cursor instead since that's literally all mpv cares about.
|
|
|
|
|
|
|
| |
It can happen during initialization and of course nothing good will
happen if we let this go through (i.e. segfault). Return and wait for
geometry to finish setting up in the wayland stuff before doing the
initial resize.
|
|
|
|
|
|
|
|
|
| |
Very dumb. I can't remember if it was always like this or if I broke it
at some point, but clearly each wl_output should just be freed in
remove_output. Freeing it if it happens to be wl->current_output only
works for that one monitor, so remove that whole line. This has to
happen before we close the wayland connection so reorder the uninit a
little bit.
|
|
|
|
|
|
|
|
|
|
|
|
| |
--no-config should prevent loading user files of any type: configs,
cache, etc. For cache files, this case wasn't properly handled and it
was assumed they would always get something. vo_gpu's shader cache
actually already handles this, so it was left untouched. In theory,
demuxer cache should never have this issue because saving it to disk is
disabled by default (and likely that will never change), but go ahead
and change it for consistency's sake. Fixes some segfaults with
--no-config and various combinations of settings (particularly
--vo=gpu-next).
|
|
|
|
|
|
|
|
|
|
|
| |
4502522a7aee093c923e79a65e4684ea2634af30 changed the way mpv handled and
saved cached files. In particular, it made a separate boolean option for
actually enabling cache and left the *-dir options as purely just a path
(i.e. having a dir set didn't mean you save cache). This technically
regressed people's configs, so let's just turn the cache on by default.
Linux users already expect random stuff in ~/.cache and well everyone
else can just live with some files possibly appearing in their config
directory.
|
|
|
|
| |
I goofed this up.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an option for allowing pointer events to pass through the mpv
window. This could be useful in cases where a user wants to display
transparent images/video with mpv and interact with applications beneath
the window. This commit implements this functionality for x11 and
wayland. Note that whether or not this actually works likely depends on
your window manager and/or compositor. E.g. sway ignores pointer events
but the entire window becomes draggable when you float it (nothing under
the mpv window receives events). Weston behaves as expected however so
that is a compositor bug. Excuse the couple of completely unrelated
style fixes (both were originally done by me).
|
|
|
|
| |
VOCTRL is processed on VO thread.
|
|
|
|
|
| |
Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is
requested.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Suggested by @sfan5. Naturally, "no" disables all drag and drop
behavior.
|
|
|
|
| |
POLLERR is only returned in `.revents` and is ignored in `.events`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this changes mp_image_new_ref() to handle allocation failure itself
instead of doing it at its many call-sites (some of which never checked
for failure at all).
also remove MP_HANDLE_OOM() from the call sites since this is not
necessary anymore.
not all the call-sites have been touched, since some of the caller might
be relying on `mp_image_new_ref(NULL)` returning NULL.
Fixes: https://github.com/mpv-player/mpv/issues/11840
|
|
|
|
| |
mediacodec_embed is a `vo` and not a `hwdec`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when vo_drm_init() fails inside of preinit(), uninit() will be called as
part of cleanup with vo->drm being NULL and thus `drm->fd` would lead to
null dereference.
and since vo_drm_uninit() closes drm->fd, destroy_framebuffer() ends up
using a closed fd.
according to the drm-gem manpage [0]:
> If you close the DRM file-descriptor, all open dumb-buffers are
> automatically destroyed.
so remove the destroy_framebuffer() loop entirely, which fixes both the
issues.
[0]: https://www.systutorials.com/docs/linux/man/7-drm-gem/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I originally left `drmprime_overlay` as higher priority because
`drmprime` was new, and because I didn't have any hardware where both
worked (only one or the other) so I couldn't compare relative
performance, and if only one worked, the priority didn't matter.
But with time and more usage, we've reached a point where we can say we
would recommend using `drmprime` in situations where both work, and
we've also been able to identify hardware where both do indeed work and
it seems that `drmprime` is more reliable.
So, let's flip them.
|
|
|
|
| |
For better or worse.
|
|
|
|
|
| |
Adds the missing upstream values that were exposed by the new gamut
mapping API.
|
|
|
|
|
|
| |
It was done once before but later reverted for testing reasons. This
time it's permanent though since I can test this VO on ARM and with an
up to date system.
|
|
|
|
|
| |
1.27 would have been nicer but ubuntu 22.04 is on 1.25 so we'll just
compromise.
|
|
|
|
| |
This lets us remove some ifdefs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using a display-* video-sync mode, it is possible for buffers with
a matching id to already have an image associated with them (i.e. the
compositor hasn't releas |