2009-02-08 03:27:30 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2009-02-08 03:27:30 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
2009-02-08 03:27:30 +00:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2009-02-08 03:27:30 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2015-04-13 07:36:54 +00:00
|
|
|
* with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2009-02-08 03:27:30 +00:00
|
|
|
*/
|
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#ifndef MPLAYER_X11_COMMON_H
|
|
|
|
|
#define MPLAYER_X11_COMMON_H
|
2002-03-07 17:50:25 +00:00
|
|
|
|
2010-01-04 19:04:33 +00:00
|
|
|
#include <stdint.h>
|
2010-07-23 00:30:44 +00:00
|
|
|
#include <stdbool.h>
|
2002-03-08 20:14:08 +00:00
|
|
|
#include <X11/Xlib.h>
|
|
|
|
|
#include <X11/Xutil.h>
|
|
|
|
|
|
2014-05-06 18:24:35 +00:00
|
|
|
#include "common/common.h"
|
2020-07-08 20:25:08 +00:00
|
|
|
#include "osdep/atomic.h"
|
2014-05-06 18:24:35 +00:00
|
|
|
|
2017-10-10 13:51:16 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
#if !HAVE_GPL
|
|
|
|
|
#error GPL only
|
|
|
|
|
#endif
|
|
|
|
|
|
2008-04-19 04:45:16 +00:00
|
|
|
struct vo;
|
2013-12-21 19:11:45 +00:00
|
|
|
struct mp_log;
|
2008-04-19 04:45:16 +00:00
|
|
|
|
2014-08-16 19:43:13 +00:00
|
|
|
#define MAX_DISPLAYS 32 // ought to be enough for everyone
|
|
|
|
|
|
|
|
|
|
struct xrandr_display {
|
|
|
|
|
struct mp_rect rc;
|
|
|
|
|
double fps;
|
2014-11-05 23:58:24 +00:00
|
|
|
char *name;
|
2015-01-26 01:18:47 +00:00
|
|
|
bool overlaps;
|
2018-11-01 01:00:03 +00:00
|
|
|
int atom_id;
|
2014-08-16 19:43:13 +00:00
|
|
|
};
|
|
|
|
|
|
2008-04-20 04:36:34 +00:00
|
|
|
struct vo_x11_state {
|
2013-09-11 22:56:41 +00:00
|
|
|
struct mp_log *log;
|
2016-03-15 21:11:31 +00:00
|
|
|
struct input_ctx *input_ctx;
|
2019-11-29 11:50:50 +00:00
|
|
|
struct m_config_cache *opts_cache;
|
2019-11-27 19:30:13 +00:00
|
|
|
struct mp_vo_opts *opts;
|
2008-04-20 06:34:27 +00:00
|
|
|
Display *display;
|
2016-07-20 18:52:08 +00:00
|
|
|
int event_fd;
|
|
|
|
|
int wakeup_pipe[2];
|
2008-04-21 00:14:37 +00:00
|
|
|
Window window;
|
2008-04-21 01:59:00 +00:00
|
|
|
Window rootwin;
|
2014-12-09 20:28:07 +00:00
|
|
|
Window parent; // embedded in this foreign window
|
2008-04-21 01:59:00 +00:00
|
|
|
int screen;
|
|
|
|
|
int display_is_local;
|
2013-02-17 15:35:44 +00:00
|
|
|
int ws_width;
|
|
|
|
|
int ws_height;
|
2017-01-19 15:30:38 +00:00
|
|
|
int dpi_scale;
|
2014-05-06 18:24:35 +00:00
|
|
|
struct mp_rect screenrc;
|
2015-12-06 17:39:09 +00:00
|
|
|
char *window_title;
|
2013-01-26 21:37:47 +00:00
|
|
|
|
2014-08-16 19:43:13 +00:00
|
|
|
struct xrandr_display displays[MAX_DISPLAYS];
|
|
|
|
|
int num_displays;
|
2016-07-18 11:06:38 +00:00
|
|
|
int current_icc_screen;
|
2014-08-16 19:43:13 +00:00
|
|
|
|
2014-08-17 13:38:47 +00:00
|
|
|
int xrandr_event;
|
2022-06-16 22:39:14 +00:00
|
|
|
bool has_mesa;
|
|
|
|
|
bool has_nvidia;
|
2014-08-17 13:38:47 +00:00
|
|
|
|
2014-05-17 19:32:11 +00:00
|
|
|
bool screensaver_enabled;
|
2014-05-18 20:16:53 +00:00
|
|
|
bool dpms_touched;
|
2017-08-20 07:11:07 +00:00
|
|
|
double screensaver_time_last;
|
2008-04-21 00:43:03 +00:00
|
|
|
|
x11: support xorg present extension
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
2022-06-10 16:49:38 +00:00
|
|
|
struct mp_present *present;
|
2022-06-22 04:13:44 +00:00
|
|
|
bool use_present;
|
x11: support xorg present extension
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
2022-06-10 16:49:38 +00:00
|
|
|
int present_code;
|
|
|
|
|
|
2012-01-14 13:09:44 +00:00
|
|
|
XIM xim;
|
|
|
|
|
XIC xic;
|
2013-04-03 23:13:56 +00:00
|
|
|
bool no_autorepeat;
|
2012-01-14 13:09:44 +00:00
|
|
|
|
2013-01-27 11:01:08 +00:00
|
|
|
Colormap colormap;
|
2008-04-21 01:19:43 +00:00
|
|
|
|
2008-04-21 01:50:29 +00:00
|
|
|
int wm_type;
|
x11: avoid wasteful rendering when possible
Because wayland is a special snowflake, mpv wound up incorporating a lot
of logic into its render loop where visibilty checks are performed
before rendering anything (in the name of efficiency of course). Only
wayland actually uses this, but there's no reason why other backends
(x11 in this commit) can't be smarter. It's far easier on xorg since we
can just query _NET_WM_STATE_HIDDEN directly and not have to do silly
callback dances.
The function, vo_x11_check_net_wm_state_change, already tracks net wm
changes, including _NET_WM_STATE_HIDDEN. There is an already existing
window_hidden variable but that is actually just for checking if the
window was mapped and has nothing to do with this particular atom. mpv
also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same
as being minimized but according to the spec, that's not neccesarily
true (in practice, it's likely that these are the same though). Anyways,
just keep track of this state in a new variable (hidden) and use that
for determing if mpv should render or not.
There is one catch though: this cannot work if a display sync mode is
used. This is why the previous commit is needed. The display sync modes
in mpv require a blocking vsync implementation since its render loop is
directly driven by vsync. In xorg, if nothing is actually rendered, then
there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so
it returns immediately. This, of course, results in completely broken
video. We just need to check to make sure that we aren't in a display
sync mode before trying to be smart about rendering. Display sync is
power inefficient anyways, so no one is really being hurt here. As an
aside, this happens to work in wayland because there's basically a
custom (and ugly) vsync blocking function + timeout but that's off
topic.
2022-04-07 03:36:30 +00:00
|
|
|
bool hidden; // _NET_WM_STATE_HIDDEN
|
x11: if the WM supports _NET_FRAME_EXTENTS, don't wait for map
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.
2014-09-15 16:42:09 +00:00
|
|
|
bool window_hidden; // the window was mapped at least once
|
|
|
|
|
bool pseudo_mapped; // not necessarily mapped, but known window size
|
2013-07-18 12:05:39 +00:00
|
|
|
int fs; // whether we assume the window is in fullscreen mode
|
2008-04-21 01:50:29 +00:00
|
|
|
|
2019-03-11 04:37:24 +00:00
|
|
|
bool mouse_cursor_visible; // whether we want the cursor to be visible (only
|
|
|
|
|
// takes effect when the window is focused)
|
|
|
|
|
bool mouse_cursor_set; // whether the cursor is *currently* *hidden*
|
2018-10-11 04:38:57 +00:00
|
|
|
bool has_focus;
|
2014-05-23 18:27:14 +00:00
|
|
|
long orig_layer;
|
2008-04-21 01:41:52 +00:00
|
|
|
|
2013-02-15 18:47:34 +00:00
|
|
|
// Current actual window position (updated on window move/resize events).
|
2014-05-17 01:29:36 +00:00
|
|
|
struct mp_rect winrc;
|
2014-08-16 19:43:13 +00:00
|
|
|
double current_display_fps;
|
2013-02-15 18:47:34 +00:00
|
|
|
|
|
|
|
|
int pending_vo_events;
|
|
|
|
|
|
x11_common: fix window mapping, refactor window creation/resize handling
vo_opengl creates an invisible window with VOFLAG_HIDDEN in order to
test whether the OpenGL context is useable. The visible window is
created at a later point. This has been broken forever (in vo_gl,
now called vo_opengl_old, it could be avoided by disabling auto-
detection explicitly using the "yuv" sub-option). Avoiding
VOFLAG_HIDDEN only mitigates the issue, and a related bug can still
happen with some window managers (see below).
As a hack, code was added to vo_gl to destroy the (hidden) window so
that all state was destroyed. Later, more hacks were added to deal with
some caveats that came with recreating the window, such as probing for
the context up to 4 times.
Attempt to fix the problem properly. There were two problems: first,
the window was not resized to video size before mapping. This was the
main cause for the placement issue, e.g. mapping the window as 320x200,
and then resizing it. Second, mpv tried to force the window position
with XSetWMNormalHints and PPosition with values it just read with
XGetGeometry. This messes up the window manager's default placement.
It seems to be a race condition, and behavior is different across
various WMs too: with IceWM, the window manager's placement is usually
preferred, and with Fluxbox, mpv's position is preferred. mpv's default
position is centering the window on the screen, which is much nicer for
video in general than typical WM default placement, so it's possible
that this bug was perceived as a feature. (Users who want this have to
use --geometry="50%:50%", doing this by default is probably not safe
with all WMs.)
Since the old code was hard to follow and full of issues, it's easier
to redo it. Move general window creation stuff out of the
vo_x11_config_vo_window function, and move the resize logic into it.
This has been tested on IcwWM, Fluxbox, awesome, Unity/Compiz.
2013-03-02 16:08:37 +00:00
|
|
|
// last non-fullscreen extends (updated on fullscreen or reinitialization)
|
2014-05-17 01:29:36 +00:00
|
|
|
struct mp_rect nofsrc;
|
x11_common: fix window mapping, refactor window creation/resize handling
vo_opengl creates an invisible window with VOFLAG_HIDDEN in order to
test whether the OpenGL context is useable. The visible window is
created at a later point. This has been broken forever (in vo_gl,
now called vo_opengl_old, it could be avoided by disabling auto-
detection explicitly using the "yuv" sub-option). Avoiding
VOFLAG_HIDDEN only mitigates the issue, and a related bug can still
happen with some window managers (see below).
As a hack, code was added to vo_gl to destroy the (hidden) window so
that all state was destroyed. Later, more hacks were added to deal with
some caveats that came with recreating the window, such as probing for
the context up to 4 times.
Attempt to fix the problem properly. There were two problems: first,
the window was not resized to video size before mapping. This was the
main cause for the placement issue, e.g. mapping the window as 320x200,
and then resizing it. Second, mpv tried to force the window position
with XSetWMNormalHints and PPosition with values it just read with
XGetGeometry. This messes up the window manager's default placement.
It seems to be a race condition, and behavior is different across
various WMs too: with IceWM, the window manager's placement is usually
preferred, and with Fluxbox, mpv's position is preferred. mpv's default
position is centering the window on the screen, which is much nicer for
video in general than typical WM default placement, so it's possible
that this bug was perceived as a feature. (Users who want this have to
use --geometry="50%:50%", doing this by default is probably not safe
with all WMs.)
Since the old code was hard to follow and full of issues, it's easier
to redo it. Move general window creation stuff out of the
vo_x11_config_vo_window function, and move the resize logic into it.
This has been tested on IcwWM, Fluxbox, awesome, Unity/Compiz.
2013-03-02 16:08:37 +00:00
|
|
|
|
2010-07-23 00:30:44 +00:00
|
|
|
/* Keep track of original video width/height to determine when to
|
|
|
|
|
* resize window when reconfiguring. Resize window when video size
|
|
|
|
|
* changes, but don't force window size changes as long as video size
|
|
|
|
|
* stays the same (even if that size is different from the current
|
|
|
|
|
* window size after the user modified the latter). */
|
2014-05-17 01:29:36 +00:00
|
|
|
int old_dw, old_dh;
|
2010-07-23 00:30:44 +00:00
|
|
|
/* Video size changed during fullscreen when we couldn't tell the new
|
|
|
|
|
* size to the window manager. Must set window size when turning
|
|
|
|
|
* fullscreen off. */
|
|
|
|
|
bool size_changed_during_fs;
|
x11_common: fix window mapping, refactor window creation/resize handling
vo_opengl creates an invisible window with VOFLAG_HIDDEN in order to
test whether the OpenGL context is useable. The visible window is
created at a later point. This has been broken forever (in vo_gl,
now called vo_opengl_old, it could be avoided by disabling auto-
detection explicitly using the "yuv" sub-option). Avoiding
VOFLAG_HIDDEN only mitigates the issue, and a related bug can still
happen with some window managers (see below).
As a hack, code was added to vo_gl to destroy the (hidden) window so
that all state was destroyed. Later, more hacks were added to deal with
some caveats that came with recreating the window, such as probing for
the context up to 4 times.
Attempt to fix the problem properly. There were two problems: first,
the window was not resized to video size before mapping. This was the
main cause for the placement issue, e.g. mapping the window as 320x200,
and then resizing it. Second, mpv tried to force the window position
with XSetWMNormalHints and PPosition with values it just read with
XGetGeometry. This messes up the window manager's default placement.
It seems to be a race condition, and behavior is different across
various WMs too: with IceWM, the window manager's placement is usually
preferred, and with Fluxbox, mpv's position is preferred. mpv's default
position is centering the window on the screen, which is much nicer for
video in general than typical WM default placement, so it's possible
that this bug was perceived as a feature. (Users who want this have to
use --geometry="50%:50%", doing this by default is probably not safe
with all WMs.)
Since the old code was hard to follow and full of issues, it's easier
to redo it. Move general window creation stuff out of the
vo_x11_config_vo_window function, and move the resize logic into it.
This has been tested on IcwWM, Fluxbox, awesome, Unity/Compiz.
2013-03-02 16:08:37 +00:00
|
|
|
bool pos_changed_during_fs;
|
2008-04-21 01:19:43 +00:00
|
|
|
|
2020-12-13 23:44:36 +00:00
|
|
|
/* The geometry/autofit option was changed while the window was maximized.
|
|
|
|
|
* Wait until the state changes to resize. */
|
|
|
|
|
bool pending_geometry_change;
|
|
|
|
|
|
2008-04-21 01:09:26 +00:00
|
|
|
XComposeStatus compose_status;
|
|
|
|
|
|
2013-01-02 11:55:52 +00:00
|
|
|
/* XShm stuff */
|
|
|
|
|
int ShmCompletionEvent;
|
|
|
|
|
/* Number of outstanding XShmPutImage requests */
|
|
|
|
|
/* Decremented when ShmCompletionEvent is received */
|
|
|
|
|
/* Increment it before XShmPutImage */
|
|
|
|
|
int ShmCompletionWaitCount;
|
|
|
|
|
|
2014-01-04 00:16:44 +00:00
|
|
|
/* drag and drop */
|
|
|
|
|
Atom dnd_requested_format;
|
2015-08-29 09:13:22 +00:00
|
|
|
Atom dnd_requested_action;
|
2014-01-04 00:16:44 +00:00
|
|
|
Window dnd_src_window;
|
|
|
|
|
|
2014-03-18 19:38:23 +00:00
|
|
|
/* dragging the window */
|
|
|
|
|
bool win_drag_button1_down;
|
2015-01-26 01:18:47 +00:00
|
|
|
|
|
|
|
|
Atom icc_profile_property;
|
2008-04-20 04:36:34 +00:00
|
|
|
};
|
|
|
|
|
|
2013-01-26 21:37:47 +00:00
|
|
|
int vo_x11_init(struct vo *vo);
|
|
|
|
|
void vo_x11_uninit(struct vo *vo);
|
2016-07-25 09:28:06 +00:00
|
|
|
void vo_x11_check_events(struct vo *vo);
|
2012-07-27 00:40:38 +00:00
|
|
|
bool vo_x11_screen_is_composited(struct vo *vo);
|
2015-09-30 21:31:34 +00:00
|
|
|
bool vo_x11_create_vo_window(struct vo *vo, XVisualInfo *vis,
|
2013-02-13 15:33:01 +00:00
|
|
|
const char *classname);
|
2015-09-30 21:31:34 +00:00
|
|
|
void vo_x11_config_vo_window(struct vo *vo);
|
x11: avoid wasteful rendering when possible
Because wayland is a special snowflake, mpv wound up incorporating a lot
of logic into its render loop where visibilty checks are performed
before rendering anything (in the name of efficiency of course). Only
wayland actually uses this, but there's no reason why other backends
(x11 in this commit) can't be smarter. It's far easier on xorg since we
can just query _NET_WM_STATE_HIDDEN directly and not have to do silly
callback dances.
The function, vo_x11_check_net_wm_state_change, already tracks net wm
changes, including _NET_WM_STATE_HIDDEN. There is an already existing
window_hidden variable but that is actually just for checking if the
window was mapped and has nothing to do with this particular atom. mpv
also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same
as being minimized but according to the spec, that's not neccesarily
true (in practice, it's likely that these are the same though). Anyways,
just keep track of this state in a new variable (hidden) and use that
for determing if mpv should render or not.
There is one catch though: this cannot work if a display sync mode is
used. This is why the previous commit is needed. The display sync modes
in mpv require a blocking vsync implementation since its render loop is
directly driven by vsync. In xorg, if nothing is actually rendered, then
there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so
it returns immediately. This, of course, results in completely broken
video. We just need to check to make sure that we aren't in a display
sync mode before trying to be smart about rendering. Display sync is
power inefficient anyways, so no one is really being hurt here. As an
aside, this happens to work in wayland because there's basically a
custom (and ugly) vsync blocking function + timeout but that's off
topic.
2022-04-07 03:36:30 +00:00
|
|
|
bool vo_x11_check_visible(struct vo *vo);
|
2013-05-15 16:17:18 +00:00
|
|
|
int vo_x11_control(struct vo *vo, int *events, int request, void *arg);
|
x11: support xorg present extension
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
2022-06-10 16:49:38 +00:00
|
|
|
void vo_x11_present(struct vo *vo);
|
|
|
|
|
void vo_x11_sync_swap(struct vo *vo);
|
2016-07-20 18:52:08 +00:00
|
|
|
void vo_x11_wakeup(struct vo *vo);
|
|
|
|
|
void vo_x11_wait_events(struct vo *vo, int64_t until_time_us);
|
2003-07-01 21:37:20 +00:00
|
|
|
|
2015-11-06 20:20:23 +00:00
|
|
|
void vo_x11_silence_xlib(int dir);
|
|
|
|
|
|
2016-12-30 18:53:46 +00:00
|
|
|
bool vo_x11_is_rgba_visual(XVisualInfo *v);
|
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#endif /* MPLAYER_X11_COMMON_H */
|
