summaryrefslogtreecommitdiffstats
path: root/video/out/x11_common.c
Commit message (Collapse)AuthorAgeFilesLines
* x11: ignore mouse enter/leave events due to pointer grabwm42015-03-111-0/+4
| | | | | | | | | | | If you click on a window that doesn't have a focus, a LeaveNotify followed by a EnterNotify event can be generated. The former will have mode set to NotifyGrab, the latter to NotifyUngrab. This will make the player think the mouse left the window, even though this is not the case. Ignore these and only react to those with mode set to NotifyNormal. Probably fixes #1672, and some other strange issues on some WMs.
* x11: fix VOCTRL_GET_WIN_STATEwm42015-03-091-0/+1
| | | | | | | | | | Do not rely on the pointed-to argument to be initialized; VOCTRLs are supposed to completely overwrite them on success (or not to touch them on failure). The currently only caller of VOCTRL_GET_WIN_STATE initializes the value before calling this, so this is merely about correctness and didn't lead to any actual bugs.
* vo_opengl/x11: fix automatic ICC profile loadingMartin Herkt2015-03-071-0/+3
| | | | | | | | | | | | mpv would attempt to load ICC profiles several times during VO init even if no window is displayed. This potentially causes it to load a profile for a different screen than it is going to be displayed on, thereby invalidating the profile cache and rebuilding the LUT every single time. It would not unload a previously loaded profile when the video window is moved to a display without an installed profile. Fix these issues and tweak the log messages a little.
* input: add MOUSE_ENTER keybinding.torque2015-02-181-1/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* x11: fix uninitialized variable readswm42015-02-141-1/+1
| | | | This line of code ended up in the wrong block in commit cd6dfcbe.
* x11: add XK_Cancel to the list of special keysMartin Herkt2015-02-141-0/+1
| | | | | Some IR receivers emit this key by default for remote control buttons. Make it mappable.
* x11: return a framerate even if no window is mappedwm42015-02-131-8/+11
| | | | | Falls back to the first display in the list returned by xrandr. Not entirely correct, but makes some people happy (see #1575).
* x11: make all XF86 special keys mappablewm42015-02-131-0/+7
| | | | | | | | Makes all keys documented in XF86keysym.h mappable. This requires the user to deal with numeric keycodes; no names are queried or exported. This is an easy way to avoid adding all the hundreds of XF86 keys to our X11 lookup table and mpv's keycode/name list.
* video/out: cosmetics: rename VO_EVENT_ICC_PROFILE_PATH_CHANGEDwm42015-01-261-2/+2
| | | | | Remove the "PATH" bit, because VOCTRL_GET_ICC_PROFILE returns an in- memory profile, and not a path. (This was changed a while ago.)
* vo_opengl, x11: implement icc-profile-autowm42015-01-261-4/+33
| | | | | | | | | | | | | | | | | This queries the _ICC_PROFILE property on the root window. It also tries to reload the ICC when it changes, or if the mpv window changes the monitor. (If multiple monitors are covered, mpv will randomly select one of them.) The official spec is a dead link on freedesktop.org, so don't blame me for any bugs. Note that this assumes that Xinerama screen numbers match the way mpv enumerates the xrandr monitors. Although there is some chance that this matches, it most likely doesn't, and we actually have to do complicated things to map the screen numbers. If it turns out that this is required, I will fix it as soon as someone with a suitable setup for testing the fix reports it.
* x11: remove unnecessary codewm42015-01-231-3/+0
|
* x11: fix initial state for --on-all-workspaceswm42015-01-171-0/+6
|
* x11: add --on-all-workspaces option and propertywm42015-01-161-0/+10
| | | | Fixes #1469.
* x11: minor cleanupwm42015-01-161-18/+4
| | | | No reason for these functions to exist separately...
* command: unify handling of fullscreen and other VO flagswm42015-01-161-0/+2
| | | | | | | | 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.
* x11: explicitly query map status when waiting for map eventwm42015-01-121-0/+6
| | | | | | | | 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.
* x11: support XEmbedwm42015-01-121-0/+49
| | | | | | | | | | | | 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.
* x11: make display-names property stricterwm42015-01-041-1/+3
| | | | | | | | | | | | | | 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.
* x11: make display-names property observablewm42015-01-031-0/+2
| | | | Reuse MP_EVENT_WIN_STATE for this.
* x11: fix mysterious issue with window embedding on OpenBoxwm42014-12-181-1/+1
| | | | | | | | | | | | | | | | | | | 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.
* x11: minor improvementswm42014-12-181-8/+7
| | | | | | 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.
* x11: copy WinID optionwm42014-12-091-16/+21
| | | | For the purpose of making "--wid" setable at any time.
* x11: fix crashwm42014-11-231-1/+1
| | | | Broken by previous commit. Oops.
* x11: fix crash with --wid=0 and vo_xv/vo_x11wm42014-11-231-2/+5
| | | | | | | But seriously, don't use --wid=0, don't use vo_xv, and _especially_ don't use vo_x11. Fixes #1284.
* vo/x11: implement VOCTRL_GET_DISPLAY_NAMES with xrandr names (e.g., "LVDS1")Kevin Mitchell2014-11-071-2/+18
| | | | | | | | 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.
* x11: rely on the Atom cachewm42014-11-031-11/+9
| | | | | XInternAtom() has a 64 entry hash table to avoid network accesses. Rely on this cache, instead of caching these manually.
* command: add window-minimized property (X11 only)wm42014-11-021-0/+19
| | | | | | More or less requested by #1237. Should be simple to extend this to other backends.
* x11: fix display FPS detection for interlaced modeswm42014-10-271-1/+6
| | | | | | | | | 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.
* x11: don't wait for asynchronous X resizing with window-scalewm42014-10-131-3/+4
| | | | | | | | | | | | | | | 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.)
* x11: don't wait until window is destroyedwm42014-10-111-5/+0
| | | | | | | | | | 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.
* x11: fix inverted conditionwm42014-10-091-2/+3
| | | | | | | 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.
* client API: rename --input-x11-keyboard to --input-vo-keyboardwm42014-10-091-1/+1
| | | | | Apparently we need this for Cocoa too. (The option was X11 specific in the hope that only X11 would need this hack.)
* x11: disable various features when embedding the windowwm42014-10-071-3/+5
|
* options: add --no-keepaspect-windowwm42014-10-041-1/+1
| | | | Seems silly, but was requested.
* x11: stupid workaround for XMonadwm42014-10-041-1/+5
| | | | | | | | --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.
* x11: fix --wid=0wm42014-10-021-0/+1
| | | | | | | | | | 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
* vo_vdpau: don't try to create surfaces of size 0wm42014-10-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* x11: always wait for mapped when using --widwm42014-09-291-2/+3
| | | | | | | Might help with embedding with mozplugger. I can't confirm whether it fixes the issue. See #1090.
* client API, X11: change default keyboard input handling againwm42014-09-281-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* x11: if the WM supports _NET_FRAME_EXTENTS, don't wait for mapwm42014-09-151-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* x11: remove unused functionwm42014-09-141-7/+1
|
* video: rename VOCTRL_GET_WINDOW_SIZEwm42014-09-051-2/+2
| | | | Make it clear that this accesses the un-fullscreened window size.
* x11: add rewind and forward keysKenneth Zhou2014-09-031-2/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* x11: when using --wid, inherit event flags from parent windowwm42014-08-311-5/+10
| | | | | | | | | | | | | | | | | | | 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)
* 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
| | | | | | |