summaryrefslogtreecommitdiffstats
path: root/video/out/x11_common.c
Commit message (Collapse)AuthorAgeFilesLines
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+1
| | | | | | | | | 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.
* x11: listen to xrandr eventswm42014-08-171-0/+16
| | | | | | | | | | | 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.
* x11: fix xrandr conditional compilationwm42014-08-171-1/+1
| | | | | | Oops. Fixes #1020.
* x11: fix memory leakswm42014-08-171-3/+9
| | | | Oh, we have to free this stuff. OK.
* build: drop check for XF86keysym.hwm42014-08-161-6/+1
| | | | | | 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.
* x11: use xrandr to retrieve display refresh ratewm42014-08-161-18/+66
| | | | | | | | | | | | | | | | | 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.
* video: add VO framedropping modewm42014-08-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* x11: vdpau GLX interop needs X11 threadswm42014-08-131-0/+2
| | | | | | | | | | 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.
* vo: remove vo_mouse_movement() wrapperwm42014-07-271-2/+3
| | | | So that VO backends don't have to access the VO just for that.
* x11: avoid obscure behavior when --wid is partially garbagewm42014-07-041-1/+1
| | | | | | | | | | | 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.
* x11: clear window only on initial mapwm42014-07-021-1/+2
| | | | | | | | | | | | | | | | | | | 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
* Add more constwm42014-06-111-1/+1
| | | | | | | 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.
* x11: cleanup motif hints handlingwm42014-06-061-34/+17
| | | | | | | | 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.
* vo_vaapi: cleanup error handling on initwm42014-05-281-1/+2
| | | | Close the X connection if initializing vaapi fails.
* x11: fix restoring position when leaving fullscreenwm42014-05-261-1/+2
| | | | Accidentally broken in commit 7163bf7d by inverting the condition.
* x11: fix datatype for _NET_WM_PIDwm42014-05-261-1/+1
| | | | | | | | | | 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.
* x11: un-inline GNOME layer stuffwm42014-05-231-16/+11
| | | | | | Having it as separate function is not useful. Also remove the useless vo_window parameter.
* x11: prefer NetWM hints over _WIN_LAYER for --ontopwm42014-05-231-11/+11
| | | | | | | _WIN_LAYER is apparently an old GNOME thing (also explains why there is a function vo_x11_get_gnome_layer() involved in this code). Prefer the NetWM hints over this. This just moves the NetWM case if-body over the _WIN_LAYER one.
* x11: rename identifiers using reserved namespacewm42014-05-231-8/+6
| | | | | | | You can't use identifiers starting with "_" and an uppercase letter in application programs. They are reserved by the C standard. Unrelated change: drop unused/misleading vo_wm_NETWM define.
* x11: fix NetWM ontop settingwm42014-05-231-23/+13
| | | | | | | I can only assume the old code was wrong. EWMH does not document anything with _WIN_LAYER. Instead, you have to toggle the state using a client message. We also remove these weird non-sense fallbacks, like using _NET_WM_STATE_BELOW - what the hell?
* x11: add a generic function for NetWM state settingwm42014-05-231-23/+11
| | | | And use it for fullscreening. It will also be used for fixing --ontop.
* x11: unbreak build without xineramawm42014-05-191-0/+2
|
* x11: leaving fullscreen -> reset WM hints only if neededwm42014-05-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This works around an issue in OpenBox: OpenBox apparently sizes the normal window incorrectly if aspect ratio hints are set, and the window size is off by 1 pixel. Then, when going fullscreen and leaving fullscreen again, mpv sets the hints based on OpenBox' broken window size, and as result, OpenBox sizes the window incorrectly and is off by 1 pixel again - so it's 2 pixels off in total. The error gets more visible, the more often you toggle fullscreen mode. Work this around by not setting the window hints if we don't need to. Actually we only need to do this when the video is resized during fullscreen, which happens rarely. Under normal circumstances, leaving fullscreen mode requires that the WM restores the old state. As such, this commit is not only a workaround, but actually a cleanup. Note that we do need to set the hints when leaving fullscreen if the window has resized: even though we set the hints in vo_x11_highlevel_resize (called by vo_x11_config_vo_window), this doesn't seem to have an effect (at least on IceWM), so we have to do it after that. Side note: ot seems commit 625ad57a strangely triggered the OpenBox issue according to user reports; I'm not sure why.
* x11: always check whether a window existswm42014-05-191-7/+20
| | | | | So any VOCTRL can be called at any time. Working towards removing all these config_ok checks in vo.c.
* x11: request and handle resize events of parent windows with --widwm42014-05-191-8/+10
| | | | | | | Before this commit, this was somehow polled (i.e. not the right way). Also, selects the correct window when doing --wid=0 (which is another weird special-case).
* x11: remove a duplicated linewm42014-05-181-1/+0
|
* x11: never enable DPMS if we didn't disable itwm42014-05-181-0/+3
| | | | | | | | | Enabling DPMS even though you disabled it globally is pretty unfriendly, so don't do it. Instead, we only disable DPMS if it was enabled, and only enable it if we disabled it ourselves. The other way should never happen (disabling DPMS permanently), unless mpv crashes during playback.
* x11: make screensaver code more compact, change DPMS handlingwm42014-05-171-53/+23
| | | | | | | | Reduces some code-duplication. Just call DPMSEnable/DPMSDisable, instead of DPMSForceLevel when reenabling DPMS. "Force" sounds evil, and messing with DPMS is already pretty evil. I'm not even sure that we should.
* x11: add wrapper for EWMH XSendEvent callswm42014-05-171-90/+49
|
* x11: fix Drag & Dropwm42014-05-171-1/+1
| | | | Accidentally broken in commit 95462747.
* x11: add a wrapper for XGetWindowPropertywm42014-05-171-70/+77
| | | | | | XGetWindowProperty is a really bad API, almost as if the NSA designed it. The wrapper takes care of verifying the return values and handle corner cases.
* x11: comment about gravitywm42014-05-171-0/+4
| | | | | | | | | | | | | | | | The window "gravity" influences how placement interacts with WM added borders (i.e. from decorations). This is probably what the code removed in commit c14721c8 was about. In theory, we'd probably want to set the gravity depending on the relative placement requested by the user (so that it's possible to line up the top/left video pixel with the monitor corner, as well as the bottom/right pixel - but that would be too complicated, and who cares after all?). I'm also not sure whether CenterGravity really uses the top/left corner as reference point (instead of making coordinates relative to the window center), but empirically it's correct.
* x11: replace x/y/w/h with mp_rectwm42014-05-171-92/+73
|
* x11: don't set PBaseSizewm42014-05-171-7/+0
| | | | There's apparently no reason why we should set a bogus size.
* x11: remove vo_hint memberwm42014-05-171-22/+26
| | | | | Now it's always recreated in vo_x11_sizehint(). Also, the Xlib manual says you must use XAllocSizeHints() (for ABI reasons), so do that.
* x11: always raise layer in fullscreen mode without NetWMwm42014-05-171-4/+1
|
* x11: implement --fs-screen properly, separate old code pathwm42014-05-171-65/+88
| | | | | | | Try to get the "new" code path (using NetWM/EWMH) free of hacks done for the sake of old WMs or the no-WM case. Implement --fs-screen using _NET_WM_FULLSCREEN_MONITORS.
* x11: use CenterGravity by defaultwm42014-05-171-1/+1
| | | | | | Keeps the window centered on resize. Seems nicer. (Although it's worse if 1. the default placement of the WM puts it into a monitor corner, and 2. you switch to a larger video.)
* x11: remove gravity restore codewm42014-05-171-9/+0
| | | | | | | | | | It was added with 3813c685 in 2004. I'm not really sure why this gravity stuff would be needed; apparently it has to do with misplacements with broken WMs and had to be changed on fullscreen. Just get rid of it; it works perfectly fine without on modern WMs. The thread discussing this is here: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-July/027674.html
* x11: don't cache X Atoms manuallywm42014-05-161-77/+45
| | | | | XInternAtom() already caches lookups. Even if calling XInternAtom would be always inefficient, it wouldn't matter much during normal playback.
* x11: inline a functionwm42014-05-161-9/+3
| | | | Keeping it separate seems less readable.
* x11: replace--[x11-]fstype option with --x11-netwmwm42014-05-161-108/+20
| | | | | Simplifies the code a lot. You can still use --x11-netwm=no to disable NetWM for whatever reasons.
* x11: remove a MWM hackwm42014-05-161-11/+0
| | | | This was for Motif Window Manager. No, I don't care about Motif.
* x11: remove unused stuffwm42014-05-161-18/+0
| | | | | Unfortunately, it looks like some Motif functionality is still needed to allow for --no-border.
* x11: set the fullscreen state before mapping the windowwm42014-05-151-0/+11
| | | | | | | This should get rid of some flickering. Since this actually skips all the wacky fullscreening code on startup, this might lead to certain wacky features to stop working. In this case, you'll have to use the --x11-fstype option, and disable _NETWM_STATE_FULLSCREEN usage.
* x11: clear window on mapwm42014-05-151-1/+1
| | | | | | | | | | | | | | | | vo_x11_map_window() was attempting to clear the window on map. However, it did so immediately after the map request. It probably assumed that the drawing calls for clearing the window would be queued along with the map request, and then executed in the right order. However, this assumption was wrong - the map request first has to go to the window manager (I guess?), so a lot of things happen before the window is even mapped. Fix this by moving the call to the MapNotify message handler, when the window (apparently) becomes really visible. I also tried to set CWBackPixel to black instead, but this seemed to result in flickering on manual resizing.
* x11: wait until the window is mappedwm42014-05-151-0/+11
| | | | | | | | | | | This blocks everything, until the window is actually reported as mapped. This fixes the race condition between VO initialization and mapping the window, which resulted in possibly different window sizes, leading to an immediate redraw, visible as flashing. Note that if the map event never comes for some reason, we're out of luck and will block forever.
* x11: fix potentially unaligned access in icon loaderwm42014-05-101-3/+3
| | | | | Tried to load a 32 bit value by dereferencing a uint32_t pointer, but the pointer is not guaranteed to be aligned, not even in practice.
* x11: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-061-27/+26
| | | | See previous commit.
* options: remove obsolete --fsmode-dontuseMartin Herkt2014-05-041-8/+2
|
* Fix some libav* include statementswm42014-04-191-5/+5
| | | | | | | | | | | | | Fix all include statements of the form: #include "libav.../..." These come from MPlayer times, when FFmpeg was somehow part of the MPlayer build tree, and this form was needed to prefer the local files over system FFmpeg. In some cases, the include statement wasn't needed or could be replaced with mpv defined symbols.
* x11_common: fix some problems with window draggingwm42014-03-221-1/+2
| | | | | | | | | | | | | | | | There were some bad interactions with the OSC. For one, dragging the OSC bar, and then moving the mouse outside of the OSC (while mouse button still held) would suddenly initiate window dragging. This was because win_drag_button1_down was not reset when sending a normal mouse event, which means the window dragging code can become active even after we've basically decided that the preceding click didn't initiate window dragging. Second, dragging the window and clicking on the OSC bar after that did nothing. This was because no mouse button up event was sent to the core, even though a mouse down event was sent. So make sure the key state is erased with MP_INPUT_RELEASE_ALL.
* x11: implement window dragging by grabbingwm42014-03-181-1/+33
| | | | | | | | | | | | | | | | | | We don't check whether the WM supports _NET_WM_MOVERESIZE_MOVE, but if it doesn't, nothing bad happens. There might be a race condition when pressing a button, and then moving the mouse and releasing the button at the same time; then the WM might get the message to initiate moving the window after the mouse button has been released, in which case the result will probably be annoying. This could possibly be fixed by sending _NET_WM_MOVERESIZE_CANCEL on button release, but on the other hand, we probably won't receive a button release event in this situation, so ignore this problem. The dragging is initiated only when moving the mouse pointer after a click in order to reduce annoying behavior when the user is e.g. doubleclicking. Closes #608.
* x11: fix initial VO sizewm42014-02-021-6/+7
| | | | | | | This was done incorrectly in the previous commit: the fallback size used the window size as requested with the first config call, which is the size of the hidden window in the vo_opengl case. (That damn hidden window again...)
* x11: remove apparently useless codewm42014-02-021-8/+0
| | | | | | | | | This code essentially does nothing. As far as I could find out, this actually used to do something. Then it was removed with commit efe7c39f, leaving some leftover code that didn't do anything useful. This happened 12 years ago! Also remove a commented debug printf.
* x11: fix race condition when setting aspect when leaving fullscreenwm42014-02-021-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | vo_opengl creates a hidden X11 window to probe the OpenGL context. It must do that before creating a visible window, because VO creation and VO config are separate phases. There's a race condition involving the hidden window: when starting with --fs, and then leaving fullscreen, the unfullscreened window is sometimes set to the aspect ratio of the hidden window. I'm not sure why the window size itself uses the correct size (but corrupted by the wrong aspect), but that's perhaps because the window manager is free to ignore the size hint while honoring the aspect, or something equally messed up. It turns out this happens because x11_common.c thinks the size of the hidden window is the size of the unfullscreened window. This in turn happens because vo_x11_update_geometry() reads the size of the hidden window when called in vo_x11_fullscreen() (called from vo_x11_config_vo_window()) when mapping the fullscreen window. At that point, the window could be mapped, but not necessarily. If it's not mapped, it will get the size of the unfullscreened window... I think. One could fix this by actively waiting until the window is mapped. Try to pick a less hacky approach instead, and never read the window size until MapNotify is received. vo_x11_create_window() needs a hack, because we'd possibly set the VO's size to 0, resulting e.g. in vdpau to fail initialization. (It'll print error messages until a proper resize is received.)
* options: remove --screenw and --screenhwm42014-01-111-7/+2
| | | | | | | | | Doesn't make any sense anymore. X11 (which was mentioned in the manpage) autodetects it, and everything else ignored the option values. Since for incomprehensible reasons the backends and vo.c still need to exchange information about the screensize using the option fields, they're not removed yet.
* video/out: remove pointless x/y parameter from vo_x11_config_vo_windowwm42014-01-111-1/+3
| | | | |