The "ontop" and "border" properties already used a common
mp_property_vo_flag() function, and the corresponding VOCTRLs used the
same conventions. "fullscreen" is pretty similar, but was handled
slightly similar. Change how VOCTRL_FULLSCREEN behaves, and use the same
helper function for "fullscreen" as the other flags.
For some reason, mpv sometimes does not get a MapNotify event with
GtkSocket embedding. This happens maybe 1 out of 10 times. I'm not sure
how this can happen - it certainly shouldn't. Since I was not able to
find the cause, and causes an apparent "deadlock", here's a lazy hack to
fix the misbehavior.
Seems to work with GtkSocket and passing the gtk_socket_get_id() value
via "wid" option to mpv.
One caveat is that using <tab> to move input focus from mpv to GTK does
not work. It seems we would have to interpret <tab> ourselves in this
case. I'm not sure if we really should do this - it would probably
require emulating some other typical conventions too. I'm not sure if an
embedder could do something about this on the toolkit level, but in
theory it would be possible, so leave it as is for now.
Returning the property before the window is mapped could lead to
confusing behavior, and in particular strange differences between
vo_vdpau and vo_opengl. (vo_opengl creates the window right at the
start, while vdpau waits until the first reconfigure event.) It might
even be possible that for vo_opengl random results were returned,
because the hidden window can have different placement than the actual,
final one on initial video reconfig.
Fix this by returning the property only if the window is considered
mapped. command.c handles this case specifically, and makes the property
unavailable, instead of returning an empty list.
For some reason, when using window embedding, and the window manager is
OpenBox, calling XSetWMNormalHints() before the window is mapped, the
initial window position will be off. It leaves some vertical space,
instead of placing it on the top/left corner. Suspiciously, the vertical
space is as much as a the height of normal window decoration.
I don't know what kind of issue this is. Possibly an OpenBox bug, but
then this happens even if the override-redirect flag is set. (This flag
basically tells the X server to ignore the window manager. Normally we
don't set it.) On other window managers, it works fine. So I don't know
why this is happening.
But this is easy to workaround. XSetWMNormalHints() isn't needed at all
if embedding.
Should fix#1235.
Always include the window position in winrc, even if the window
embedded. This should give the correct positions for things which still
interact with global coordinates, such as the xrandr code.
XRRGetOutputInfo contains a "name" element which corresponds to to the
display names given to the user by the "xrandr" command line
utility. Copy it into the xrandr_display struct for each display.
On VOCTRL_GET_DISPLAY_NAMES, send a copy of the names
of the displays spanned by the mpv window on.
In interlaced modes, we output fields, not complete frames, so the
framerate doubles.
The method to calculate this was borrowed from xrandr code.
Hopefully fixes#1224.
Instead of letting the window-scale property return the old value until
X11 actually executed the resize, just set the new assumed internal
window size immediately. This avoids a "lag" between setting and reading
the window-scale property, like OSD controls typically do.
Remove the additional calls from vo_x11_highlevel_resize() - they're
pointless and slightly wrong, and resize events will take care of
updating these things correctly anyway.
Fixes#1176.
("window-scale" works via VOCTRL_[S|G]ET_UNFS_WINDOW_SIZE.)
This can hang if the window was destroyed externally (or that's what I
suspect happens), and we somehow didn't receive the DestroyNotify event.
I'm not sure why we wouldn't receive this event (since it should just be
in the xlib event queue), but on the other hand there's no real need to
wait for window destruction.
This essentially reverts 97fc74e2.
Worryingly wrong. Fixes#1162.
Also fix another issue (window title was set anyway), which was why I
didn't notice this and testing it seemed to be fine.
--x11-netwm=yes now forces NetWM fullscreen, while --x11-netwm=auto
(detect whether NetWM fullsctreen support is available) is the old
behavior and still the default.
See #888.
Another fallout resulting from the changes whether or not to wait for
mapping the window. In this case, it obviously makes no sense to wait
for mapping, because the root window is always mapped. Mapping will
never happen, and it would wait forever.
Fixes#1139.
CC: @mpv-player/stable
At least on kwin, we decide to proceed without waiting for the window
being mapped (due to the frame exts hack, see commit 8c002b79). But that
leaves us with a window size of 0x0, which causes VdpOutputSurfaceCreate
to fail. This prints some warnings, although vo_vdpau recovers later and
this has no other bad consequences.
Do the following things to deal with this:
- set the "known" window size to the suggested window size before the
window is even created
- allow calling XGetGeometry on the window even if the window is not
mapped yet (this should work just fine)
- make the output surface minimum size 1x1
Strictly speaking, only one of these would be required to make the
warning disappear, but they're all valid changes and increase robustness
and correctness. At no point we use a window size of 0x0 as magic value
for "unset" or unknown size, so keeping it unset has no purpose anyway.
CC: @mpv-player/stable
Commit 64b7811c tried to do the "right thing" with respect to whether
keyboard input should be enabled or not. It turns out that X11 does
something stupid by design. All modern toolkits work around this native
X11 behavior, but embedding breaks these workarounds.
The only way to handle this correctly is the XEmbed protocol. It needs
to be supported by the toolkit, and probably also some mpv support. But
Qt has inconsistent support for it. In Qt 4, a X11 specific embedding
widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently
supports it via QWindow, but if it really does, I couldn't get it to
work.
So add a hack instead. The new --input-x11-keyboard option controls
whether mpv should enable keyboard input on the X11 window or not. In
the command line player, it's enabled by default, but in libmpv it's
disabled.
This hack has the same problem as all previous embedding had: move the
mouse outside of the window, and you don't get keyboard input anymore.
Likewise, mpv will steal all keyboard input from the parent application
as long as the mouse is inside of the mpv window.
Also see issue #1090.
Some window managers can prevent mapping of a window as a feature. i3
can put new windows on a certain workspace (with "assign"), so if mpv is
started on a different workspace, the window will never be mapped.
mpv currently waits until the window is mapped (blocking almost all of
the player), in order to avoid race conditions regarding the window
size. We don't want to remove this, but on the other hand we also don't
want to block the player forever in these situations.
So what we need is a way to know when the window manager is "done" with
processing the map request. Unfortunately, there doesn't seem to be a
standard way for this. So, instead we could do some arbitrary
communication with the WM, that may act as "barrier" after map request
and the "immediate" mapping of the window. If the window is not mapped
after this barrier, it means the window manager decided to delay the
mapping indefinitely. Use the _NET_REQUEST_FRAME_EXTENTS message as such
a barrier. WMs supporting this message must set the _NET_FRAME_EXTENTS
property on the mpv window, and we receive a PropertyNotify event. If
that happens, we always continue and cancel waiting for the MapNotify
event.
I don't know if this is sane or if there's a better mechanism. Also,
this works only for WMs which support this message, which are not many.
But at least it appears to work on i3. It may reintroduce flickering on
fullscreen with other WMs, though.
When embedding a X window, it's hard to control whether it receives
mouse/keyboard input or not. It seems the X protocol itself makes this
hard (basically due to the outdated design mismatching with modern
toolkits), and we have to take care of these things explicitly.
Simply do this by manually querying and using the parent window event
flags.
This restores some MPlayer behavior (it doesn't add back exactly the
same code, but it's very similar).
This probably has some potential to interfere with libmpv embedding, so
bump the client API minor.
CC: @mpv-player/stable (if applied, client-api-changes.rst has to be
adjusted to include the 0.5.2 release)
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.
The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
If the Xrandr configuration changes, re-read it. So if you change
display modes or screen configuration, it will update the framedrop
refresh rate accordingly.
This passes the rootwin to XRRSelectInput(), which may or may not be
allowed. But it works, and the documentation (which is worse than used
toilet paper, great job Xorg) doesn't forbid it, or in fact say anything
about what the window parameter is even used for.
This is always included in the Xorg development headers. Strictly
speaking it's not necessarily available with other X implementations,
but these are hopefully all dead.
Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr
extension to retrieve the refresh rate. Xrandr has the advantage that it
supports multiple monitors (at least the modern version of it).
For now, we don't attempt any dynamic reconfiguration. We don't request
and listen to Xrandr events, and we don't notify the VO code of changes
in the refresh rate. (The later works by assuming that X coordinates map
directly to Xrandr coordinates, which probably is wrong with compositing
window manager, at least if these use complicated transformations. But I
know of no API to handle this.)
It would be nice to drop use of the Xinerama extension too, but
unfortunately, at least one EWMH feature uses Xinerama screen numbers,
and I don't know how that maps to Xrandr outputs.
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
Xlib is not thread-safe. Or actually it is, but it's an incomprehensible
hack that was added later, and which needs to be acitvated manually
(this makes no sense). And it appears that the vdpau accesses X from the
decoder thread if GLX interop is used (and not in any other situations -
this doesn't make too much sense either).
So, just call the magic function that enables Xlib thread-safety.
Cast away the "extra" bits (since apparently Window/XID is always
32 bit unsigned). This is not striclty needed, because you're not
supposed to pass garbage to --wid, just because the upper bits are
possibly not interpreted. But if you do so, this change increases
consistency in behavior and removes a strange behavior that was
thought to be a bug.
Also see github issue #906.
Apparently clearing on every map can cause problems with vdpau when
switching virtual desktops and such. This was observed with at least
XMonad and nvidia-340.17. It's not observed on some other setups without
XMonad.
It's not clear why this happens. Normally, the window background is not
saved, so clearing should have no additional affect. It's a complete
mystery. Possible, the use of legacy X drawing commands (used to clear
the window) interferes with vdpau operation in non-trivial ways.
Work this around by clearing on initial map only. This probably only
hides the underlying issue, but good enough.
Closes#897.
CC: @mpv-player/stable
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
It seems we can't really get rid of this. There are no other hints to
remove decorations that work across all reasonable WMs, so we're stuck
with the ugly motif stuff.
But at least we can make the code for it less ugly.
Setting this property was added 12 years ago, and the code was always
incorrect. The underlying data type is "long", not "pid_t". It's well
possible that the data types are different, and the pointer to the pid
variable is directly passed to XChangeProperty, possibly invoking
undefined behavior.
It's funny, because in theory using pid_t for PIDs sounds more correct.
wm4
Kevin Mitchell
Kenneth Zhou