| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
See: https://code.videolan.org/videolan/libplacebo/-/merge_requests/659
|
|
|
|
| |
This function is used to enable/disable mouse input for win32 and unix.
|
| |
|
|
|
|
|
| |
When the window style changes, use WS_EX_TOOLWINDOW style to exclude
the window from the taskbar and Alt+Tab switching.
|
|
|
|
|
|
|
|
|
| |
This adds a new option --show-in-taskbar, which controls whether
mpv appears in taskbars. This is useful for picture-in-picture
setups where the video window should not appear in taskbars.
On X11, this can be controled by setting the
_NET_WM_STATE_SKIP_TASKBAR window state.
|
| |
|
|
|
|
| |
Fixes: 895f40e150d4 ("wayland: only perform a rescale if window is on one output")
|
|
|
|
|
|
|
| |
The protocol strongly implies that this only happens when the value
changes, and it's also what you would naturally expect. But maybe it's
worth guarding this in cause for some reason the same value twice in a
row happens.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mpv window overlapping multiple outputs with different scale values
can result in some weird behavior when dragging it from one monitor to
another one. This is due to the way some compositors implement
preferred_scale or preferred_buffer_scale (integer scale equivalent).
Depending on the scale values, mpv window has to be resized to match the
new scaling value (due to fractional scaling requiring a viewport). This
can cause the window to become smaller and no longer overlap the monitor
you were just trying to drag it to. Repeat this and the window will
become smaller and smaller. Depending on the layout, the reverse can
also happen (the window becomes larger). This can cause additional
events to fire as the preferred_scale value may change again which does
more weird things.
It seems kwin is not affected by this because their implementation of
preferred_scale sends the event only if the window is fully on the new
monitor. Honestly, this is probably more logical anyway but we should at
least deal with the other implementations better. Try to deal with it by
reworking scaling changes so they only occur when the mpv window is
fully on one monitor. If we get a preferred_scale event and there is an
overlap, save it as a pending change to be performed on the next
surface_enter or surface_leave event (whichever results in there being
only one monitor. Some weird rendering glitches can still happen during
overlap but this makes it usable again.
|
|
|
|
|
|
|
|
| |
Turns out libplacebo uses unrotated target crop in relation to source.
Use dst rect from VO, instead of extracting it from pl_frame, to avoid
another unrotating operation.
Fixes: a9354b36ca
|
|
|
|
|
|
|
|
| |
Previously if mpv's size was constrained by the compositor's configure
bounds event, there was no attempt to preserve the aspect ratio of the
given coordinates if --keepaspect (the default) was used. Be sure to
apply keepaspect to the bounded widths and heights if we are using this
event.
|
|
|
|
|
|
|
|
|
|
|
| |
The reconfigure event handles setting fullscreen, maximize, etc. We were
implictly relying on the compositor to just ignore mpv if we set a
redundant state (e.g. setting fullscreen when we're already fullscreen),
but kwin actually doesn't and operates again. This causes some subtle
issues when handling geometry on state changes. Rework the state change
calls so they are only executed if wl->geometry_configured isn't set yet
(i.e. the window just opened up for the first time). It's the only time
this is actually needed.
|
|
|
|
|
|
|
|
| |
If mpv is coming out of some locked size state (fullscreen, maximized,
tiled), the window size given by the reconfigure event should be used
assuming the --auto-window-size option is set.
Fixes 8a9749b8a563f258342450160c98e9c02ebedc96
|
|
|
|
|
| |
Use rect of the actual image instead of FBO size which includes
margins.
|
| |
|
|
|
|
|
|
|
|
|
| |
this will prevent jumping of the window size in the case the window size
was 'externally' modified and not via the window-scale property, when
using the pinch gesture.
Fixes #11594
Fixes #13799
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit was originally sparked by a change in sway. When looking at
the wording of the spec, it was believed that the rotation should be
counter-clockwise. But that was interpreted incorrectly. The rotation
direction in the spec is meant for compositors not clients. Clients
should be rotating clockwise and compositors rotate it the opposite
direction. Also see the discussion in upstream wayland*.
*: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/369
This reverts commit 27ef1725e7724f4b6899e3992ac3a884db9fbe13.
|
|
|
|
|
|
|
|
|
| |
Allows to avoid non-portable strlen usage. Also avoid "initializer
element is not constant" warnings on older GCC that doesn't like
explicit type specification in aggregate initialization.
Co-authored-by: NRK <nrk@disroot.org>
Co-authored-by: nanahi <130121847+na-na-hi@users.noreply.github.com>
|
| |
|
| |
|
|
|
|
| |
See-Also: https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036
|
| |
|
| |
|
|
|
|
|
|
|
| |
This is multiple times faster than just writing every pixel sequence
separately. Especially on slower terminal emulators. In general no need
to stress I/O, while we can just prepare the frame to print and do it
once.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is mostly motivated by missing
VK_KHR_portability_enumeration instance extension when enumerating the
devices. Which causes issues with MoltenVK which does not advertise full
Vulkan conformance.
To avoid duplicating code use pl_vk_inst_create() which correctly query
availability and enables the mentioned extension.
While at it fix the VkInstance leaking in vk_validate_dev().
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
the unfsContentFrame wasn't updated when externally resized leading to
a wrong unfs window size afterwards. update it on windowDidResize event
when not in fs, not animating and not live resizing.
|
|
|
|
|
|
|
|
|
| |
At least on some compositors, when the pointer enters a surface,
only a wl_pointer_enter event is generated, but not wl_pointer_motion.
This results in the initial mouse position being lost, which is
especially problematic when input simulation is used.
Fix this by setting the mouse position on pointer enter event.
|
|
|
|
|
|
|
|
|
|
|
| |
this broke with the recent refactor of the input handling. one of the
edge cases was not considered, where not every mouse down event has a
corresponding mouse up event, eg all double clicks or more only have one
up event after the first down event.
this was handled correctly previously.
Fixes #13777
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
split up AppHub header in obj-c and c parts and make it a bidirectional
bridging.
|
|
|
|
|
|
|
| |
win32 does not respect --native-keyrepeat option, and native key
repeat has been broken since 0ab3482f73a199b2e839ad4ec0a4b21adc1e75d5.
This lets mpv respect the --native-keyrepeat option on win32.
|
| |
|
|
|
|
| |
The backbuffer format is available.
|
|
|
|
|
| |
The target colorspace depends on whether the xv adaptor supports
setting BT.709 colorspace.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
add new app_bridge objc file for bridging between mpv core and app
functionality. replace old EventsResponder singleton with AppHub.
another step to clean up all App functionality and have one central
place for it.
|
|
|
|
|
|
|
| |
As no drivers were ever released with the unstable extension,
it's not needed anymore.
Not bumping the required headers version yet.
|
| |
|
| |
|
|
|
|
| |
also optimise option cache setup.
|
|
|
|
|
|
| |
since the option handler is not optional anymore and available on init
in cocoa-cb we don't need to duplicate this functionality in libmpv
anymore.
|
|
|
|
| |
gets rid of some unwrapping boilerplate and nil coalescing operators.
|
| |
|
| |
|
|
|
|
| |
delete now empty mpv helper
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both possible paths had bugs:
For OpenGL it passed EGL_CONTEXT_CLIENT_VERSION, which - in older versions
of the standard - was not permitted.
For GLES it always assumed EGL_CONTEXT_FLAGS_KHR to work, which belongs to the
aforementioned extension.
Ironically this was never a problem (probably saved by implementations
not being overly strict) except in 2024 on an emulated Android 14 device
that trips over this edge case. It is a mystery.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The screenshot command is documented to not overwrite existing files.
However, there is a race window between the filename is generated with
gen_fname and when the file is open to write. Specifically, the
convert_image function in this window can be very time consuming
depending on video and screenshot image format and size. This results
in existing file being overwritten because the file writing functions
don't check for the existance of file.
Fix this be opening the file in exclusive mode. Add overwrite parameter to
write_image for other operations that are documented to overwrite existing
files, like screenshot-to-file. Note that for write_avif, checking
existance is used instead because avio_open does not support exclusive
open mode.
|
|
|
|
|
| |
When a shell link is dropped onto the mpv window, the file name will be
replaced by the file name of its target so that the linked file is played.
|
|
|
|
|
|
|
| |
Fixes the issue described in https://github.com/mpv-player/mpv/issues/11862
for SDR files for non-d3d11 gpu-api. We currently don't have a smarter
way to get the real on-the-wire bpc for other APIs, so this is the best
that can be done.
|
|
|
|
| |
Needed for the next commit
|
|
|
|
| |
warning: embedding a directive within macro arguments has undefined behavior
|
| |
|
|
|
|
| |
warning: `static' is not at beginning of declaration
|
|
|
|
| |
warning: type qualifiers ignored on function return type
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream ASS specification says that all subtitles should be rendered
with color primaries and transfer matching their associated video. But
as expected after further discussion the decision has been made to
fallback to SDR mode in case of HDR video.
See-Also: https://github.com/libass/libass/blob/649a7c2e1fc6f4188ea1a89968560715800b883d/libass/ass_types.h#L233-L237
See-Also: libass/libass#297
See-Also: mpv-player#13381
Fixes: mpv-player#13673
|
|
|
|
|
|
|
|
|
| |
Windows 10 top bar height cannot be adjusted individually when
WS_CAPTION is enabled due to buggy DWM NC drawing behavior. The issue is
fixed in Windows 11.
To keep consistent window look remove the border on each side, but only
on Windows 10.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows 11 draws border regardless, so we are 1px off on window size,
blending border with one line of video. Fix that by adding the border to
our internal windows size calculation.
Windows 10 on the other hand has a bug where specifying left and top NC
area will trigger title bar drawn in full height always. Keep old
behaviour in this case. Also while there is similar "visible" border
there, it seems to be transparent on Windows 10.
For high contrast themes, don't adjust title bar height and instead
remove WS_CAPTION to have the same border all around the window, as DWM
doesn't make borders invisible in this case.
|
| |
|
| |
|
|
|
|
|
| |
If the window-maximized is set while in fullscreen, it needs to be applied
when leaving fullscreen, as noted in the comment.
|
|
|
|
|
|
|
|
|
|
|
| |
With runtime geometry change, currently it only results in a
SetWindowPos call to resize the window. However, SetWindowPos doesn't
change the window maximized state, so Windows still thinks that the
window is maximized even though it no longer covers the whole workspace.
This results in visual glitches, and if the window is dragged afterwards
it's "restored" again.
Fix this by correctly setting the window maximized state in this case.
|
|