| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This exports `current-gpu-context` property, which is the string
description of the current active GPU context. This allows scripts to
uniquely identify the platform and backend used for --vo=gpu
and --vo=gpu-next.
|
| |
|
|
|
|
|
| |
With --really-quiet the message level is -1 which is not in the
msg_lev_to_pl_log enum, so handle it explicitly.
|
|
|
|
|
|
| |
Negative values are nonsense to mpv, and can cause protocol error afterwards,
like xdg_surface::set_window_geometry which doesn't accept negative values.
Treat any negative values as zero (client determines size) for now.
|
|
|
|
|
|
| |
Needed in case the timer solution fails. Note that this will leave the
mode indicator in the language bar showing the original mode until
a key is pressed.
|
|
|
|
|
|
| |
Some IMEs initialize to composition mode for new windows, which is
undesirable for keyboard control.
Default to alphanumeric input to solve this.
|
|
|
|
|
| |
By default the IME candidate window appears on the top left corner
of the monitor. Move it to the video window for sane behavior.
|
|
|
|
| |
WM_UNICHAR is sent by some 3rd-party IMEs.
|
|
|
|
|
|
|
|
|
|
| |
The IME is useful for text input. Additionally, Alt+Shift input language
switching doesn't work when IME is disabled even when the languages don't
require IME.
Re-add the VK_PROCESSKEY logic to ensure that IME is handled properly.
Reverts bf6b981367e45c3f926d3e667bba3f3ed6e9dc37.
|
|
|
|
|
| |
We don't care about the physical state of keys, only if they are
effective or not and whether they should affect key processing.
|
|
|
|
|
|
|
|
|
|
| |
According to the xkbcommon docs, `xkb_state_mod_index_is_consumed` is
true when a modifier *may affect* key translation. A key modifier may
be consumed but not be active. See xkb documentation for this function
for further details. This breaks key modifiers in cases where
L_Shift+R_Shift for example is used to change keyboard layout with
`xkb_options grp:shifts_toggle`. Instead, replace it with a simple
check for a valid modifier.
|
|
|
|
|
|
|
|
| |
Xft.dpi is much more widely used nowadays by GUI programs compared to
the X11 screen DPI.
This is the best we can get for a vendor-neutral scaling preference
value under X11 in terms of adoption.
If Xft.dpi isn't available, the X11 screen DPI is used as a fallback.
|
|
|
|
|
|
|
|
| |
~144 DPI displays are pretty common and neither 1x nor 2x scales are
the right size for it. Allow DPI scale in unit of 0.5 to fix this.
Additionally, add a note about the current behavior of the API used
to get the scale factor.
|
|
|
|
|
|
|
|
|
|
| |
Currently, libplacebo always tries to reconfigure the d3d11 swapchain
to a 10-bit output format because disable_10bit_sdr isn't set to true,
even when an 8-bit format is explicitly requested via
--d3d11-output-format.
Fix this by passing the requested output format preference to libplacebo.
Document that this option may be ignored.
|
| |
|
|
|
|
| |
This completes the support for all supported desktop platforms.
|
|
|
|
|
|
|
|
| |
In commit c09245cdf2491211f3e0bfe47f28cc0e0a2e05c8
long-path support was enabled for mpv without actually
making sure that there was no code left that used the
old limit (260 Unicode chars) for buffer sizes.
This commit fixes all but one case.
|
| |
|
|
|
|
| |
Fixes #9325
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a result of the work I did the explicitly check for formats
supported by the vo in the f_autoconvert logic, I introduced a
regression in the handling of the rpi4_8 and rpi4_10 formats. These
require special handling because they only exist in the rpi forks and
not upstream ffmpeg, which means they don't have stable pix fmt values
that we can use directly.
Previously, we simply didn't declare them as supported, which was ok,
as nothing was really enforcing the list of supported formats, but that
has changed.
As we still can't simply use the pix fmts, I had to do a slightly
ridiculous dance to look them up by name, and if they exist, then
register them as supported.
Good times.
|
|
|
|
|
| |
57367377505b6b2edc87004fa3192d831d515aa5 mistakenly changed the mode
from 644 to 755. Change it back.
|
| |
|
|
|
|
| |
returns the NSWindow
|
| |
|
|
|
|
|
|
|
| |
The dragging hack can cause unwanted aero shake activation.
Prevent this by saving the window arrangement state before dragging,
temporarily disable it while dragging hack is active, and restore to
the original state after dragging ends.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mouse down handler checks w32->current_fs to determine whether
to begin the dragging hack. Unfortunately, the w32->current_fs value
is stale, because the input is handled asynchronously, and we cannot
wait for an up-to-date value if dragging needs to be kept resonsive.
As a result, when the fullscreen state changes after the dragging
model loop is entered, the opposite value is used, so the window stays
draggable after entering fullscreen, and becomes undraggable after
exiting fullscreen.
With the resonsiveness and model loop constraints, the up-to-date
state must be queried inside WM_MOVING messages which are sent while
dragging. The message handler now checks if the dragging hack is active
while the window is in fullscreen, and overrides the new window position
with the current one, in effect prevents the window from being moved.
The old check is also removed, so the window is now draggable after
exiting fullscreen while dragging hack is active.
|
|
|
|
|
|
|
|
|
|
|
| |
Compose key doesn't function in X11 because XFilterEvent() isn't called,
and XNInputStyle is set to a wrong value. This results in KeyPress events
for the separate keyboard inputs in the compose key input sequence
instead of the composed character, making it impossible to input certain
characters which require compose key.
Fix this by calling the required XFilterEvent() and set XNInputStyle
to the correct value.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to MS documentation, an application should return TRUE from
WM_XBUTTONUP and WM_XBUTTONDOWN if it processes these messages.
DefWindowProc generates the WM_APPCOMMAND message when it processes the
WM_XBUTTONUP message, so if an application properly handles WM_XBUTTONUP
messages, extra WM_APPCOMMAND messages won't be generated.
Because mpv doesn't properly handle these messages,
WM_XBUTTONUP causes APPCOMMAND_BROWSER_BACKWARD to be generated, resulting
in duplicated keys and improper fix 438ead7a, which prevents the processing
of the appcommand from sources other than mouse clicks.
Fix this by following the documentation, and the back and forward
appcommands can be added.
|
|
|
|
|
|
|
|
|
| |
XF86Back and XF86Forward are mostly used to navigate file and web browsers
to go back/forward in history. XF86Forward isn't recognized right now,
so add it.
Because XF86AudioForward already takes the "FORWARD" name, rename the
browse keys to GO_BACK and GO_FORWARD instead.
|
|
|
|
|
| |
Also change the example to crf=23. crf=32 is pretty bad quality, don't
give users bad usage ideas.
|
|
|
|
|
|
|
| |
Fixes chroma location for screenshots.
Also set the crop to full frame to not trip mp_image_params_equal check
if not necessary.
|
|
|
|
| |
It is useful information, not only for debugging.
|
|
|
|
| |
--screenshot-avif-pixfmt no longer defaults to yuv420p.
|
|
|
|
|
|
| |
modifier keys weren't reported when using the trackpad to scroll.
Fixes #11195
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the case the window was already set to a maximized size via geometry
or related options (100%x100%) the maximize function would try to
maximize the window again. this reset the position and slightly
increased the size further.
to prevent this only maximize on init if we really want to maximize. in
the reverse case make a noop call by passing the current zoom state.
Fixes #11193
|
|
|
|
|
|
|
|
| |
281b1d89994e3e3a9950d32fc451dff990c2320d introduced a stack use after
scope because dest_fbo can be reassigned a new pointer and then be used
by pass_draw_to_screen outside of that scope where the pointer is no
longer valid. Fix this by rearranging the variables so the assignment is
done in the same scope as the pass_draw_to_screen call instead.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
- read directly to bstr
- use talloc for OOM checks
- don't parent temporary allocation
- don't check for NULL buffer after already writting to it
|
|
|
|
| |
No longer needed after 079f67268f6f5a2ecfd12277b246b1937493c092.
|
| |
|
| |
|
|
|
|
| |
Make it easier on compiler, no need to alloca and copy things around.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The info provided for libva might be useful. Specifically on Windows it
seems to not use the error callback for what should be logged as error.
[ 0.080][v][vaapi] libva: VA-API version 1.20.0
[ 0.080][v][vaapi] libva: Trying to open <path>/vaon12_drv_video.dll
[ 0.080][v][vaapi] libva: va_openDriver() returns -1
[ 0.080][e][vaapi] Failed to initialize VAAPI: unknown libva error
As we can see only the "unknown" error is printed to the error callback
and important information is printed on the info callback. Print it to
verbose log to make it easier to find.
|
|
|
|
| |
ctx->destroy_native_ctx is guarded, but this early exit was not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the title is updated on the main thread (mandatory with cocoa)
asynchronously, because otherwise it would either deadlock when done
synchronously, lead to undefined behaviour or just crashes. the problem
here is that the c string was only copied to an NSString within that
asynchronous call, which potentially would access the pointer when it
is accessed, modified or freed by another thread. it is only safe to
access this pointer as long as the control callback wasn't returned yet.
to fix this we move the copying and creation of the String from the
c string pointer outside of the asynchronous call where the conversion
of an untyped pointer to a typed pointer is done too. since the
resulting String is a copy it's safe to be used in the asynchronous
call.
also reverting ee6ad40, since the problem was most likely an SDK problem
or the very same problem as mentioned here. i retested the crash case
again und can't reproduce it anymore. using a swift String again instead
of an NSSstring.
Fixes #12935
|
| |
|
|
|
|
|
|
|
|
| |
- Don't define _GNU_SOURCE on Windows, no need
- Define WIN32_LEAN_AND_MEAN to strip some unneded headers from
windows.h
- Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows
headers
|
|
|
|
|
|
| |
We prefer to fail fast rather than degrade in unpredictable ways.
The example in sub/ is particularly egregious because the code just
skips the work it's meant to do when an allocation fails.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly is added to resolve player command synchronization with VO
thread discussed in 477a0f83.
The current uses does not necessarily need this as they are all managed
by playloop. But for future use with other params that will be handy.
Those params are mostly to observe current state of VO and does not
necessarly need to be locked along with frame drawing, that changes the
params once at the end.
|
|
|
|
|
|
|
|
|
|
|
| |
Only vaapi-copy variant as nothing can map D3D12 resources currently.
And even if we would add resource sharing to D3D11 it would invoke copy
at some point, so there is no point really. Maybe in the future when
libplacebo get smarter about resource sharing on Windows, but practical
advantages are really small. I've tested it with Vulkan <-> D3D11
sharing and GPU <-> GPU copy is still invoked. Better than CPU memcpy,
something for the future.
|
|
|
|
| |
Useful for logging
|
|
|
|
| |
To be able to reuse them in other parts of code.
|
|
|
|
| |
There is nothing d3d11 about those adapters.
|
|
|
|
|
|
|
|
|
| |
Up to 2x playback rate is the most we can offer currently. Should work
fine for most kernels with radius <= 2.
This avoids limitation of hwdecs number of frames in-flight.
Fixes: #12927
|
|
|
|
|
|
|
|
| |
there is 1px border at the top of the window that is not covered by our
title bar and the video below is visible. this broke in some newer macOS
version even so the calculation of size and position of the title bar is
still correct. add 1px the the height of the title bar to cover up the
unwanted border.
|
|
|
|
|
|
|
| |
left wheel and right wheel was swapped. this was copied from the old
cocoa backend. a delta <0 is a right scroll, >0 is a left scroll.
Fixes #12899
|
|
|
|
|
|
|
| |
These are less likely to be modified from run to run, and with the
avoidance of redundant re-saving we can get away with a larger size.
This is enough to save 10 3DLUTs at typical sizes.
|
|
|
|
|
|
|
| |
Backwards compatibility wrapper can be bumped once sufficient libplacebo
version is a minimum dependency.
See-Also: https://github.com/mpv-player/mpv/pull/12902
|
|
|
|
|
|
|
|
|
|
|
| |
I have no idea why this code is such a convoluted mess of options and
possibilities. First of all, why is dumping both caches to a single file
even a supported use case? Why is the cache path generated multiple
times, once for saving and once for loading, instead of just generated
once and stored? Why even create a pl_cache if you're not going to
save/load it? Why so much code duplication?
I don't know. But I rewrote it in a way that makes far more sense to me.
|
|
|
|
| |
talloc_free is safe to call with NULL.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This change prevents unwanted adjustments. Generally, screenshots
shouldn't invoke pl_queue_update, as this action could cull the already
mapped frames in the queue.
|
|
|
|
|
| |
This is mainly for debugging purposes, as it should't happen in normal
use. If it does, it needs fixing.
|
| |
|