On X11, aspect ratio constraint is applied on the window manager side,
so whenever keepaspect and keepaspect-window change, mpv should update
the size hint immediately, otherwise the new constraint isn't applied.
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.
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.
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.
8e793bde78 made that changing geometry
while maximized has no effect until the window is unmaximazed. However,
this behavior is inconsistent with setting window-scale on all of win32,
wayland, and x11, which always unmaximizes the window and sets the
window size.
Since setting geometry is conceptually similar to setting window-scale
(both change the window size), they should have the same behavior.
If not fullscreen, unmaximize window on runtime geometry change to
keep the behavior consistent with window-scale.
Currently, setting geometry on runtime only changes the window size
but not the position. This is because reset_size is only set if
the window size is changed, and vo_x11_highlevel_resize doesn't set
the window position without force_window_position enabled. Fix this
by setting the related flags and perform a window move when
geometry is updated.
Fixes 8e793bde78.
Currently, VO dragging logic is hardcoded into each VO, where a left mouse
button down event unconditionally begins dragging if the VO dragging test
passes. This method is extremely unflexible as the VO has no knowledge of
what is happening in the input system: while begin dragging with the second
click of a doubleclick is undesired, it cannot determine whether a click
is a double click or not because it's determined by the input system.
The better way to do it is to handle it somewhere in the downstream
consumers of the events instead, as they have more information to make
this decision. The input system is the perfect place for this as the logic
for checking doubleclick already exists. So just issue a begin-vo-dragging
command if it detects a left mouse button down which isn't also a
doubleclick in this case, and delete all hardcoded VO dragging logic
in win32, x11, and wayland.
Note that this solution hardcodes left mouse button down for now, but
because the VO dragging is now centralized, it's possible to make more
improvements, such as a deadzone mechanism to fix the conflict with
MBTN_LEFT mouse bind.
This allows begin-vo-dragging command to initialize a vo dragging request
for x11. The last mouse button press event is used for _NET_WM_MOVERESIZE.
The hard-coded left mouse button down trigger is scheduled to be removed
in a later commit.
Several related things but in a nutshell makes it more like wayland.
1. Remove unneeded --hidpi-window-scale checks. The backend should
always report the actual dpi value regardless of what this option
says.
2. Remove dpi_scale factors from UNFS_WINDOW_SIZE VOCTRLs. It makes
things more complicated and unintuitive for no reason. A window scale
of 1 should mean 1. It annoyed a few years ago in #9437, and I agree
with them (wayland was never implemented like this).
3. Change the dpi log messages to be more brief and remove the unneeded
comments about prescaling.
Begin the _NET_WM_MOVERESIZE window dragging in ButtonPress event
to match the behavior of win32 and wayland, simplify logic by dropping
the win_drag_button1_down hack required by the old method, and fix a race
condition described in commit 19f101db68,
which happens when moving the mouse and releasing the button at the same time.
The race condition can be easily triggered when using a touch screen
(tested with libinput driver), where a tap is translated to MotionNotify,
ButtonPress, MotionNotify, and ButtonRelease in sequence, with the last 2
events having the same timestamp. This has caused some window managers to
not stop dragging after the ButtonRelease, resulting in window being stuck
in dragging state after a single tap.
Some X11 window managers support controlling the title bar independently
from other window decorations with _MOTIF_WM_HINTS. This allows hiding
the title bar while keeping other decorations like the resizing borders.
Let mpv respect the --title-bar option on X11 so --no-title-bar can hide
the title bar only like on win32.
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.
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.
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.
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.
Fixes a899e14b which changed clamp from 0 to 1 ms which effectivelly
introduced 1ms sleep always, even if requested until_time_ns is in the
past and should request 0 timeout.
While at it also fix mp_poll wrapper to respect negative timeout which
should mean infinite wait.
Also keep the 37d6604 behaviour for very short timeouts, but round only
the ones > 100us, anything else is 0.
Fixes: a899e14b
When this was originally written, the queuing/list approach was
deliberately removed since it adds more complication and xorg/wayland
don't really use it anyway. In practice, you only really have one frame
in flight with presentation timestamps. However, one slight annoyance is
that the drm code has its own thing which is almost exactly the same and
does its own calculations. Ideally, we'd port drm to this instead, but
the implementation there takes into account N-frames in flight which
probably does actually work. So we need to make present_sync smarter and
be able to handle this.
mpv does actually have its own linked list implementation already which
is a good fit for this. mp_present becomes the list and each
mp_present_entry has its own set of timestamps. During initialization,
we create all the entries we need and then simply treat it like a queue
during the lifecycle of the VO. When an entry is fully used
(present_sync_get_info), then we remove it from the list, zero it out,
and append it to the end for future use. This avoids needing to allocate
memory on every frame (which is what drm currently does) and allows for
a reasonable number of in flight frames at the same time as this should
never grow to some obscene number. The nice thing is that current users
of present_sync don't need to change anything besides the initialization
step.
On linux, several platforms poll for events over a fd. This has ms
accuracy, but mpv's timer is in ns now so lots of precision is lost. We
can use an mp_poll wrapper to use ppoll instead which takes a timespec
directly with nanosecond precision. On systems without ppoll this falls
back to old poll behavior. On wayland, we don't actually use this
because ppoll completely messes up the event loop for some unknown
reason.
In many cases, this is purely cosmetic because poll still only accepts
microseconds. There's still a gain here however since
pthread_cond_timedwait can take a realtime ts now.
Additionally, 37d6604d70 changed the value
added to timeout_ms in X11 and Wayland to ensure that it would never be
0 and rounded up. This was both incomplete, several other parts of the
player have this same problem like drm, and not really needed. Instead
the MPCLAMP is just adjusted to have a min of 1.
So far all the keypad keys except for `0` and `,` mapped to the same
MP_KEY_* independent of numlock state, even though different key codes
are received.
Now all the alternative functions map to appropriate MP_KEY_* defines,
with missing ones added.
Without doing this, --fs --fs-screen=1 wouldn't actually end up on the
desired screen since the sizehint was never sent. Also check the
screen-name variants for an empty string as well so the option can
properly "undo" itself (not sure if this has any practical effect).
mpv mixes xinerama and randr usage together which gets kind of
confusing and is also pretty stupid. Xinerama is completely unneccesary
today since randr can do everything it can do and much more. Remove it.
This reworks a lot of the window/geometry handling stuff to be centered
completely around xrandr_display plus some other tweaks to the geometry
handling. An important concept is that current_icc_screen is changed
into current_screen and used more generously since it is useful for
things besides just icc profiles.
There really is no reason to not just hard require randr 1.4. xorg added
1.4 support in 2012 and someone somehow using an xorg server older than
that today surely has several other problems.
This deliberately wasn't being done when mpv was embedded
(fbccddb48b). There are some applications
that would benefit from mpv setting a title since they don't do so
themselves (such as tabbed), but at the same time some others would
probably rather not have this behavior (like smplayer). Add an option
that allows an embedded mpv to set the title if the user wishes.
Fixes#11528.
XDestroyWindow() is called immediately after, which also unmaps window
if needed. according to the manpage:
> If the window specified by the w argument is mapped, it is unmapped
> automatically.
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.
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).
Some platforms (wayland) apparently have a lot of trouble with drag and
drop. The default behavior is still the same which is basically obeying
what we get from the window manager/compositor, but the --drag-and-drop
option allows forcibly overriding the drag and drop behavior. i.e. you
can force it to always replace the playlist or append at the end. This
only implements this in X11 and Wayland but in theory windows and macos
could find this option useful (both hardcode the shift key for
appending). Patches welcome.
mpv's window resizing logic always automatically resized the window
whenever the video resolution changed (i.e. advancing forward in a
playlist). This simply introduces the option to make this behavior
configurable. Every windowing backend would need to implement this
behavior in their code since a reconfigure event must always be a
resize. The params of the frame changed so you either have to resize the
window to the new size of the params or make the params the same size as
the window. This commit implements it for wayland, win32, and x11.
There's several functions that are used for initializing mpv on a
certain platform (x11, wayland, etc.). These currently are all int, but
they actually return 1 and 0 like a boolean. This gets a bit confusing
because actual vo preinit functions return 0 and -1 instead. Just make
these all bool instead and return true/false to make it clearer.
Since the modesetting driver now has TearFree support with integration into
xpresent, it's important that xpresent is used with the modesetting driver
to get the correct vsync timing when a frame is delayed by one vblank
interval due to a pending page-flip enqueued by a different entity. The
modesetting driver ensures that the xpresent extension reports the correct
presentation timing when TearFree is used; mpv just needs to listen to it.
Add the modesetting driver to the xpresent whitelist so mpv can get the
correct presentation completion timing when modesetting TearFree is used.
This is also helpful for when xpresent performs page flips directly in the
modesetting driver and a natural delay in the display pipeline causes a
page flip to be delayed by one vblank interval or more.
currently only supported on x11.
one practical use-case of this is wanting to embed something (such as
dmenu) into the mpv window to use as a menu/selection. there might be
other use-cases as well (e.g doing some shenanigans with `xdotool` or
whatnot).
it's currently possible to:
* listen for 'current-window-scale' change (to check if the
window has been created or not)
* call an external tool like `xdo` or `xdotool` and grab the xid
from mpv's pid.
however it adds unnecessary dependency on external tools when mpv is
fully capable of easily providing this information.
closes: #10918
