Also, if the position is valid, set it to 1 / INF. Windows interprets 0
as non-progress.
Progress is quantized into uint8 range, it is good enough for this
use-case. This avoids unnecessary vo_control and
ITaskbarList3::SetProgressValue calls and should be visually
indistinguishable in practice.
Fixes#14282
The values provided since last disjoint event may include significant
error in case there are periods of slower presentation. We should look
at more localized/current values of presentation.
For more accurate approximation of vsync rate I plan to add better
algorithm to calculate it.
Revert this commit alone as it is not neccessary and gives as separation
from other changes for better regression testing.
This reverts commit f27767f59e.
If mpv is launched with --fs, the x11 code tries to reset the size and
position of the window when the fullscreen exits. This has bad behavior
with multiple monitors because the saved nofsrc is not reliable in many
situations. Particularly if the window manager moves the fullscreen
window somewhere else while mpv is fullscreen. The result will be that
exiting fullscreen always goes back to screen 0.
Fix this by translating the rc coordinates of the nofsrc rc to the new
monitor when we're leaving fullscreen from an initial --fs case. By
giving get_current_display a specific rc, we can return what xrandr
display the coordinates are associated with and decide if the nofsrc
should be translated to its new location. After that bit of math, the
usual move/resize logic takes care of the rest but this time it actually
works off of the correct position. Fixes#14226.
This is required by the wayland protocol to keep the logical keyboard
state consistent.
Quoting 9e4f256927:
> In the wl_keyboard logical state, this event sets the active surface to
> the surface argument and the keys currently logically down to the keys
> in the keys argument.
The idle inhibit protocol specifies that the compositor may ignore the
idle inhibitor if the surface is occluded. In the case of
vo_dmabuf_wayland, wl->surface corresponds to typical black bars when
the video aspect ratio is different than the display's. So in many
cases, wl->surface is actually occluded by wl->video_surface which sits
above it. Change this so that the idle inhibitor is created on
wl->callback_surface instead which is either wl->surface for the gpu VOs
or wl->video_surface for vo_dmabuf_wayland. Fixes#14206.
This might not always be correct depending on filtering done in VS. But
unless VS send us all the metadata we have to get it from somewhere.
Fixes dynamic frame metadata, which was copied from fmt_in, initialized
only upon reinitialization.
Fixes crashes caused by the use of stale pointers.
Fixes: #13956
Conditional jump or move depends on uninitialised value(s)
at 0x10FE22: drm_prime_remove_handle_ref (drm_prime.c:144)
by 0x10FCCD: drm_prime_destroy_framebuffer (drm_prime.c:107)
by 0x10FEB1: set_current_frame (hwdec_drmprime_drm.c:73)
by 0x11054F: overlay_frame (hwdec_drmprime_drm.c:223)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Uninitialised value was created by a heap allocation
at 0x484713C: realloc (vg_replace_malloc.c:1437)
by 0x10258B: ta_realloc_size (ta.c:195)
by 0x10325D: ta_xrealloc_size (ta_utils.c:298)
by 0x10FDBF: drm_prime_add_handle_ref (drm_prime.c:133)
by 0x10FC57: drm_prime_create_framebuffer (drm_prime.c:87)
by 0x1102FF: overlay_frame (hwdec_drmprime_drm.c:188)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Conditional jump or move depends on uninitialised value(s)
at 0x10FCE4: drm_prime_destroy_framebuffer (drm_prime.c:109)
by 0x10FEB1: set_current_frame (hwdec_drmprime_drm.c:73)
by 0x11054F: overlay_frame (hwdec_drmprime_drm.c:223)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Uninitialised value was created by a heap allocation
at 0x484713C: realloc (vg_replace_malloc.c:1437)
by 0x10258B: ta_realloc_size (ta.c:195)
by 0x10325D: ta_xrealloc_size (ta_utils.c:298)
by 0x10FDBF: drm_prime_add_handle_ref (drm_prime.c:133)
by 0x10FC57: drm_prime_create_framebuffer (drm_prime.c:87)
by 0x1102FF: overlay_frame (hwdec_drmprime_drm.c:188)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process
is blocking and takes a few seconds. It also needlessly increases power consumption.
Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls
`cuInit` before running all interop inits. However, the first checks in the interops do not
require cuda initialization, so we only need to call `cuInit` after those checks.
This commit splits the interop `init` function into `check` and `init`. `check` can be called without
initializing the Cuda backend, so cuInit is only called *after* the first interop check.
With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents
`dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily,
making them start faster and decreasing power consumption on laptops.
Fixes: https://github.com/mpv-player/mpv/issues/13668
by default utilises the color space of the screen on which the window is
located. if a specific value is defined, it will instead be utilised.
depending on the chosen color space the macOS EDR (HDR) support is
activated and that OS's transformation (tone mapping) is used.
Fixes#7341
WS_POPUP windows cannot be maximized, so instead of forcing it with
unavoidable side-effects, change the window style before maximizing to
make it work correctly.
This makes the context menu items accessible from the window menu,
which can be opened by either right-clicking on the title bar or
left-clicking on the mpv icon on the title bar.
Currently if VO init fails, the context menu is leaked. Additionally,
init/uninit are in the VO thread, while other accesses are in the GUI
thread.
Fix this by moving them to the GUI thread, similar to other resources.
This also lets init function take the mpv HWND in the next commit.
If we get either preferred_scale or preferred_buffer_scale this early
during initialization the wl->scaling value should be immediately
updated instead of being deferred until later for correct geometry.
Fixes#14019.
After explorer is restarted while show-in-taskbar is false, toggling
show-in-taskbar no longer puts mpv back to the taskbar until it's
unfocused and refocused.
My guess of how this works is that the HWND of the taskbar is cached,
and setting the WS_EX_TOOLWINDOW style internally uses this value to
show/hide the taskbar button. But after explorer is restarted it no
longer works until its taskbar state needs to change (such as focusing).
Only then it realizes the HWND is no longer valid and refreshes it.
Fix this by following MS documentation on this: the window needs to be
hidden before changing the style, and be shown after that. This
unfortunately can sometimes introduce a brief window flash, but it
fixes the problem.
Abstract out EGL, and allow choosing between EGL and vulkan at runtime.
vf_gpu_egl.c contains GL specific context and creation/destroy code,
vf_gpu_vulkan.c contains Vulkan specific. This allows vf_gpu being
built in systems where EGL is not available and where Vulkan is
available.
the Screen property localizedName returns a none unique dynamic name
that doesn't allow a specific selection of a Screen on every OS boot.
the name consists of the vendor name and model name (eg DELL U2723QE).
if the same model display is connected to the system several times,
macOS starts to add numbers to the localizedName (eg DELL U2723QE (1)),
that may not be associated to the same Screen on every OS boot or
connecting the display. it also changes the name of the first connected
display by adding that numeration. this makes it impossible specify the
proper screen with the screen-name option every time.
to circumvent this we remove the enumeration from the name and instead
add the serial number to the display-names property. this makes the
actual Screen unique and none dynamic. furthermore the selection of a
screen by name will check for equality for the old localizedName, simple
name without enumeration, serial number and the combined name with
serial number. this makes it possible to select the screen by either of
those names and identifiers, and keeps backwards compatibility with the
old behaviour.
Examples:
localized name (System Settings name): DELL U2723QE, DELL U2723QE (1)
simple name: DELL U2723QE
serial number: 123456789
combined name: DELL U2723QE (123456789)
When this was originally implemented, the fixed conversion factor was
accidentally reverse engineered. It was left as is though. Instead, use
the wl_fixed_from_int helper, so it's more obvious what is going on
here.
DXGI debug interface encapsulate multiple message queues, which allows
to get validation not only for D3D11 calls, but also DXGI ones.
Also this makes leak detector not report self debug interface as alive
like it was before. And same as with validation, it has ability to
detect more alive objects, not being limited to D3D11.
Not all cards support gbm which means the creation of the gbm device
will fail. However during the uninit process, the destruction of the
device was unconditionally done which leads to a segfault. Guard it
instead. Fixes#13929.
Previously, the code required a check against the old saved geometry to
make sure the size and/or position was different before updating. The
doesn't work with the previous changes that allow a geometry value to be
set again with the same value as before. It would probably be nicer to
check against something that always keeps track of the actual window
size in real time, but it seems geometry in x11 doesn't quite work that
way so we'll do it the easier way instead.
Now that obj_settings_list is used for GPU contexts, detailed
descriptions can be added so that --gpu-context=help can print
the descriptions of the GPU contexts using standard
obj_settings_list help printing.
