There are good reasons to bind Ctrl+WHEEL_UP/WHEEL_DOWN to video-zoom:
- They are ubiquitous and familiar key bindings to represent zooming
operations, which are used in all popular web browsers, document viewers,
and document editors.
- Because WHEEL_UP/WHEEL_DOWN are scaled with high-resolution scrolling
input devices like touchpads, this allows smooth zooming.
- This makes "pinch to zoom" with touchpads and touchscreens work out of
box on Windows, since by default applications receive these key inputs
for pinch gesture.
- It had been considered to bind these keys to window-scale instead.
However, this results in horrible UX as the keybinds work only when the
mouse pointer is over the mpv window, and if the window shrinks during
this operation, the window below mpv now receives these keybinds,
resulting in unwanted zooming for that window, which violates the principle
of least surprise.
this partially reverts commit 7b5a258. back then the only properly
working vo on macOS was cocoa-cb (libmpv). it would always use the
deprecated opengl cocoa backend or no vo at all. because of that libmpv
was moved to the top of the auto-probing order, so the preferred vo
was used on macOS only.
we now have a working vulkan gpu/gpu-next backend on macOS which should
be the new default vo. though disabling the auto-probing again for
libmpv would probably cause the undesired behaviour on macOS that
cocoa-cb would never be auto selected again. especially if not build
with vulkan support or without vulkan driver on macOS, this would lead
to no video output at all. so instead of completely reverting the
mentioned commit, we instead move libmpv to the bottom of the
auto-probing order but only auto select it when mpv was built with
cocoa-cb support. this restores the previous behaviour on all other
platforms besides macOS, but also lets us auto select cocoa-cb if
supported.
Deprecated upstream 1cc24d7495
We need to reallocate the context here because `avcodec_free_context`
also frees the context, and we want to reuse the context with some
reconfig.
this fixes a crash on quit, when a CATransaction from a system owned
thread/event is happening at the same time. locking the context
synchronises these access and prevents the race condition.
the draw operation induced by any display call from the CAOpenGLLayer
doesn't need that lock, since the display function already does lock
that current context.
Fixes#11681
Homebrew finally pulled the plug on lua 5.1*, and it is no more. So we
have to change to a different lua package and the only other choice is
luajit (no 5.2 in homebrew). We used to use luajit for the ci, but
649556b2b6 switched it to lua 5.1. As
explained there, luajit 2.0 was horribly bugged and not usuable for mpv
and the build had to do dumb hacks to work around it. I expected 5.1 to
last a bit longer than a couple of years, but luckily it seems like
luajit in homebrew now pulls a luajit 2.1 version (some rolling release
thing or however upstream works). The details don't really matter for
us since 2.1 does not have all the awful issues that 2.0 used to have.
So just switch to luajit again.
*: 57d73df3ba
Since 03cf150ff3, the only purpose of this
VOCTRL was to signal a redraw to the vo. It actualy could have been
removed in 531868fe0d, but this was
missed. The UPDATE_VIDEO flag is better anyway because it allows us to
handle a wide variety of options scattered around that require the VO to
update itself and redraw. We can remove both of the custom callbacks in
vo.c and only leave the VOCTRL_VO_OPTS_CHANGED one. Additionally, that
commit also introduced vo_set_want_redraw, but this is redundant and not
needed. The VOs that use VOCTRL_UPDATE_RENDER_OPTS already set
vo->want_redraw, and those are the only VOs where these options are
relevant in the first place. So we can remove this as well and just let
the big callback in player/command do everything.
It's only necessary to check the existance of cursor_shape_manager.
Also drop the pointer check to handle multi-seat since a removed seat
sets the cursor_seat to NULL.
For VOCTRL_SET_CURSOR_VISIBILITY, set cursors visibility for all seats.
The return is VO_NOTAVAIL is none of the seats have cursor, and
VO_FALSE if setting visibility failed for at least one seat.
The cursor_shape_device is per pointer, which is per seat. Handle it
together with other seat objects. This in turn also handles cursor
visibility per seat.
On a multi-seat setup, wl_registry_global advertises wl_seat multiple times,
one for each seat. if wl->seat is already set, the previous value will be
overwritten, preventing it from being freed.
Additionally, if the latter seat doesn't have the capabilities of the
former seat, the keyboard/pointer/touch input devices will be destroyed
because the current wl_seat_capabilities doesn't distinguish between
different seats. This casues keyboard/pointer/touch not working if the
latter seat has no such capabilities.
Fix this by implementing multi-seat support.
This allows receiving inputs from all devices on all seats.
All seat-specific objects (wl_keyboard/pointer/touch, wl_data_device)
are grouped with their respective seats so they can be managed together.
Note that currently inputs from all seats are interleaved with each other
and modify the same global input states.
If libplacebo manages to create a vulkan swapchain that allows
alpha composition mode to be controlled by the DWM API,
this makes it runtime changeable.
Specify cAlphaBits in PIXELFORMATDESCRIPTOR makes the pixel format
transparent, as is already the case for d3d11. Also makes the
window transparent when --alpha=yes is used.
Works on --vo=gpu and --vo=gpu-next.
25b66256d7 originally added this
property, but it did not add it to the property notification. This is
possibly because the window id doesn't appear to change on x11 even when
toggling VOs at runtime. However, windows uses this property and
apparently the id changes there so we should signal updates when
appropriate. Fixes#13495.
On wayland, depending on the wl_output protocol version used,
the display-names property can have different values. Mention
this in the documentation, like for other platforms.
Previously, libplacebo would fail to render the image since mpv was
feeding it bogus bitmaps with 0 width/height. An easy way to encounter
this would be to set sub-scale to 0 with bitmap/image subs.
Document the use cases for enabling or disabling the wheel preprocessing.
Also note that this option has no effect on any filtering already done
by the OS/driver.
This adds --input-preprocess-wheel option, which can be used to control
whether to preprocess received wheel events.
Commit 937128697f added preprocessing of
wheel events to prevent the accidental scrolling of another direction
when one direction is being scrolled for touchpads, which is problematic
with the default wheel bindings where unrelated functions (seeking and
volume) are used for the 2 directions.
However, this behavior is undesirable in the following situations:
- When custom wheel bindings are used so that the 2 directions are used
for closely related actions, such as panning. With preprocessing,
diagonal movement is impossible.
- Since the wheel deadzone was introduced to prevent accidental scrolling
for touchpads, this filtering provides no benefit for high resolution
unidirectional mouse wheels, while causing a regression where scrolling at
least 0.125 units is required to trigger the event, causing input delay.
By adding this option, these two use cases are addressed.
The current documentation lacks clarity regarding the interaction
between the `repeatable` and `complex` options. Through an analysis
of the source code (`player/lua/defaults.lua` and
`player/js/defaults.js`), it was observed that the `repeatable` option
is only meaningful when the `complex` option is not enabled.
Additionally, the `complex` option in the existing documentation is
confusing, actually `fn` can be called on key repeat when `complex` is
`true` and `repeatable` is not `true`.
To address these issues, the documentation for the `repeatable` option
was updated to specify that it only applies when the `complex` option is
not set to `true`. Furthermore, the description of the `complex` and
`event` were revised to acknowledge the occurrence of key repeat events.
It is possible to have data with empty block that contains additions. In
which case the block would not be added and the additions would leak.
Found by fuzzing.
This is technically due to the previous commits that made subtitle
rendering more efficient by eliminating redraws, but working around this
particular edge case is useless. The sub-clear-on-seek option was
originally introduced in d5940fabcd and
specifically is a workaround for completely broken mkv files. There is
no reason to use it otherwise. Because that option disables all
duplicate checking and the previous commits rework subtitle rendering in
the still image case to be dependent on keeping track of packets, the
end result is that you will get the same line rendered multiple times.
However the important case of broken mkv files with duplicate ReadOrder
fields still work just fine with --no-video. So instead of bothering
trying to make this option "work", just clarify that stuff can break
since, again, there's no reason to use it other than as a workaround for
broken files.
The previous commits optimized sub redrawing on still images/terminal so
mpv wouldn't redraw so much. There is a gap though. It only assumes
static subtitles. Since ASS can be animated, those types of subtitles
will always need redraws so we need to build in specific detection for
this. We need to build a whitelist of events in ASS that are considered
animations and then flag the packet. Additionally, there's a bunch of
annoying bookkeeping that has to be done since packets can be dropped on
seeks and so on.
der richter
nanahi
llyyr
Julian Orth
Dudemanguy
Jose Maldonado aka Yukiteru
gaesa
Kacper Michajłow
Thomas Weißschuh