summaryrefslogtreecommitdiffstats
path: root/video/out/x11_common.h
Commit message (Collapse)AuthorAgeFilesLines
* x11_common: fix window x/y position when updating geometry on runtimenanahi2024-03-171-0/+1
| | | | | | | | | | | 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 8e793bde78f00fbb64223db30851c6d080c4abeb.
* x11_common: implement VOCTRL_BEGIN_DRAGGINGnanahi2024-03-011-0/+2
| | | | | | | 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.
* x11_common: handle window dragging in ButtonPress eventnanahi2024-02-211-3/+0
| | | | | | | | | | | | | | | 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 19f101db680f966a6e56035a16784541be390982, 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.
* x11_common: allow DPI scale in unit of 0.5nanahi2024-01-101-1/+1
| | | | | | | | ~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.
* various: sort some standard headersNRK2023-10-201-2/+3
| | | | | | | | | | | | since i was going to fix the include order of stdatomic, might as well sort the surrouding includes in accordance with the project's coding style. some headers can sometime require specific include order. standard library headers usually don't. but mpv might "hack into" the standard headers (e.g pthreads) so that complicates things a bit more. hopefully nothing breaks. if it does, the style guide is to blame.
* osdep: remove atomic.hNRK2023-10-201-1/+1
| | | | | | | replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with explicit _Atomic qualified types. also add missing config.h includes on some files.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-101-1/+1
| | | | | | | | | | | | 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, 37d6604d70c8c594de2817db26356c4c950ac0fd 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.
* x11: remove xinerama and refactor window geometryDudemanguy2023-08-201-2/+3
| | | | | | | | | | | 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.
* player: add --auto-window-resize optionDudemanguy2023-03-021-3/+2
| | | | | | | | | | | 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.
* vo: change vo_platform_init to boolDudemanguy2023-01-081-1/+1
| | | | | | | | 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.
* x11: avoid XPresent API calls when it's not neededDudemanguy2022-06-221-1/+1
| | | | | | | | | | | This commit kind of mixes several related things together. The main thing is to avoid calling any XPresent functions or internal functions related to presentation when the feature is not auto-whitelisted or enabled by the user. Internally rework this so it all works off of a use_present bool (have_present is eliminated because having a non-zero present_code covers exactly the same thing) and make sure it updates on runtime. Finally, put some actual logging in here whenever XPresent is enabled/disabled. Fixes #10326.
* x11: support xorg present extensionDudemanguy2022-06-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* x11: use xrandr providers for driver detectionDudemanguy2022-06-191-0/+2
| | | | | | | | | | | | | | Unfortunately there's a certain company that makes graphics drivers that are harder to deal with. The next commit aims to implement presentation, but some empirical testing from users show that it's actually broken. Give up and just tap into Xrandr so we can figure what drivers (or well, providers by the extension terminology) are driving the screen. Basically if we find intel, amd, or radeon, assume it's a Mesa driver. If we find nvidia, then it must be nvidia. This detection requires randr 1.4 (which means using presentation in mpv secretly depends on randr 1.4), but this protocol version is nearly a decade old anyway so probably 99.9% of users are fine. Do the version query check and all that anyway just to be on the safe side.
* x11: avoid wasteful rendering when possibleDudemanguy2022-04-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* x11: update geometry/autofit opts on runtimeDudemanguy2020-12-141-0/+4
| | | | | | If the window is maximized, we can't change the size immediately. In that case, we set a bool and wait for the state to change before triggering the resize.
* x11: remove terrible xdg-screensaver hackwm42020-07-081-8/+1
| | | | | | | | | | | | | | I'm tired of dealing with this frequent spawning of xdg-screensaver when debugging and what not. xdg-screensaver was never a serious tool anyway, it's more like some self-deprecating joke by FDO folks. This will affect X11 on GNOME and other DEs. I'm singling out GNOME though, because they are the ones actively sabotaging any sane technical solutions and community cooperation. I have been accused of taking it out on innocent GNOME users, while none of this will reach GNOME developers. Of course that is not the intention.
* x11: use new option stuff to implement fullscreenwm42019-11-291-0/+1
| | | | | | | | | | | | | | | - remove VOCTRL_FULLSCREEN and VOCTRL_GET_FULLSCREEN - have your own m_config_cache for the fullscreen option (vo->opts_cache cannot be used because you lose per-option change notifications, and it'd be a mess anyway) - use VOCTRL_VO_OPTS_CHANGED to update it (it's used for convenience) - when updating it, check for the fullscreen option (wasn't sure how to do it best; currently, it compares the raw option pointers, but this could be changed) - do not send VO_EVENT_FULLSCREEN_STATE on FS change - instead write the option on FS change (assign in opt. struct + m_config_cache_write_opt)
* x11_common: don't use vo->opts directlywm42019-11-271-0/+1
| | | | | | | | | Use x11->opts instead of vo->opts. This doesn't matter currently, and x11->opts is actually set to vo->opts. However, there's a chance that either option access changes, or that the way backends integrate with struct vo changes. This is just a preemptive change to make this less of a mess, and it's generally a good idea to reduce accesses to struct vo anyway.
* x11: fix ICC profiling for multiple monitorsslatchurie2019-09-211-0/+1
| | | | | | | | | To find the correct ICC profile X atom, the screen number was calculated directly from the xrandr order of the screens. But if a primary screen is set, it should be the first Xinerama screen, even if it is not the first xrandr screen. Calculate the the proper atom id for each screen.
* x11: fix cursor hiding initial statePhilip Sequeira2019-03-161-2/+3
| | | | | | | | | Regression from 8e3308d687c3acdd0d572015b06efd5b492d93ee. Broken cases were: * --no-cursor-autohide acted like --cursor-autohide=always. * --cursor-autohide-fs-only always hid the cursor if starting non-fullscreen; entering fullscreen at least once fixed it.
* x11: don't hide cursor if window isn't focusedwm42018-12-061-1/+3
| | | | | | | I found this sort of annoying. You could argue that the "frontend" should maybe contain this logic, but who cares.
* Add checks for HAVE_GPL to various GPL-only source fileswm42017-10-101-0/+5
| | | | | | | | This should actually cover all of them, if you take into account that some unchanged GPL source files include header files with such checks. Also this was done already for the libaf derived code. This is only for "safety" and to avoid misunderstandings.
* Revert "x11: use xdg-screensaver suspend/resume"Martin Herkt2017-08-201-5/+6
| | | | This reverts commit 6694048272619b7f91d161c040b818ff63e65279.
* x11: use xdg-screensaver suspend/resumewm42017-08-151-6/+5
| | | | | | If it doesn't work this time, I'll remove all X11 screensaver code. Fixes #4763.
* x11: pseudo HiDPI scalingwm42017-01-191-0/+1
| | | | | | | | | | | | | | | | Scale the window by the assumed DPI scaling factor, using 96 DPI as base. For example, a screen that reports 192 DPI is assumed to have a DPI scale factor 2. The window will then be created with twice the size. For robustness reasons, we accept only integer DPI scales between 1 and 9. We also error out if the X and Y scales are very different, as this most likely indicates a multiscreen system with botched size reporting. I'm not sure if reading the X server's DPI is such a good idea - maybe the Xrdb "Xft.dpi" value should be used instead. The current method follows what xdpyinfo does. This can be disabled with --hidpi-window-scale=no.
* vo_opengl: x11: move RGBA visual test to x11_common.cwm42016-12-301-0/+2
| | | | | | | | So that the EGL code can use it too. Also print the actual FB config ID, instead of nonsense. (I _think_ once in the past a certain GLX implementation just used numeric config IDs casted to EGLConfig - or at least that would explain this nonsense.)
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+1
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* x11: do not accidentally discard event flagswm42016-07-251-1/+1
| | | | | | | | | It seems vo_x11_check_events() was supposed to return the currently flagged events and reset them. But there are many places where vo_x11_check_events() is called without checking its return value. This could lead to forgotten events. Change the code such that they can't get lost.
* x11: stop using vo.event_fdwm42016-07-201-0/+4
| | | | Instead let it do its own event loop wakeup handling.
* x11: skip ICC update on every window movewm42016-07-181-0/+1
| | | | | | | Don't just cause vo_opengl to update the ICC profile every time the window is moved. Instead, explicitly check if the screen was changed. Mostly untested.
* x11: move vo->input_ctx accesses to x11->input_ctxwm42016-03-151-0/+1
| | | | | | Reduces VO access and makes the code more self-contained. (One day the windowing backend code should not access the VO anymore. We're just not quite there yet.)
* vo: get rid of vo_get_window_title()wm42015-12-061-0/+1
| | | | | | | | | | | It always was a weird artifact - VOCTRLs are meant _not_ to require special handling in the code that passes them through (like in vo.c). Removing it is also interesting to further reduce the dependency of backends on struct vo. Just get rid of it. Removing it is somewhat inconvenient, because in many situations the UI window is created after the first VOCTRL_UPDATE_WINDOW_TITLE. This means these backends have to store it in a new field in their own context.
* vo_opengl: x11: silence error messages when using legacy GL contextwm42015-11-061-0/+2
| | | | | | | | glXCreateContextAttribsARB() by design can throw some X11 errors. We ignore these, but we generally still print error messages to the terminal. This was confusing/annoying users, so silence it. The stupid part is that the Xlib error handler is global, so we have to be slightly careful here.
* x11: separate window creation and configurationwm42015-09-301-1/+2
| | | | | | | | | | | | | | | | | | | This gets rid of an old hack, VOFLAG_HIDDEN. Although handling of it has been sane for a while, it used to cause much pain, and is still unintuitive and weird even today. The main reason for this hack is that OpenGL selects a X11 Visual for you, and you're supposed to use this Visual when creating the X window for the OpenGL context. Which means the X window can't be created early in the common X11 init code, but the OpenGL code needs to do something before that. API-wise you need separate functions for X11 init and X11 window creation. The VOFLAG_HIDDEN hack conflated window creation and the entrypoint for resizing on video resolution change into one function, vo_x11_config_vo_window(). This required all platform backends to handle this flag, even if they didn't need this mechanism. Wayland still uses this for minor reasons (alpha support?), so the wayland backend must be changed before the flag can be entirely removed.
* x11: drag and drop append with modifierKevin Mitchell2015-08-301-0/+1
| | | | | | | If the drag and drop action is anything other than XdndActionCopy, append the dropped files rather than replacing the existing playlist. With most file managers, this will mean at least pressing shift while dropping.
* x11: move GCs and background clearing to vo_xvwm42015-07-011-3/+0
| | | | vo_xv.c is the only place where these things are used.
* x11: remove clear on mapwm42015-07-011-1/+0
| | | | | | | | Less code, and avoids a black flash on start. In theory it could happen that we map the window, and then don't have a frame to draw - but mapping the window is done in the exact moment we have a new frame to display.
* x11: never forcefully terminate xdg-screensaver processwm42015-05-181-1/+3
| | | | | | It sometimes happens on exit, and it's probably a bad idea. If the process hangs on exit (possibly due to stupid hardcoded timeouts it's doing), mpv will also hang now, unfortunately.
* x11: actually disable screensaverwm42015-04-151-0/+6
| | | | | | | | | | | | | | | | | | | We already use 2 screensaver APIs when attempting to disable the screensaver: XResetScreenSaver() (from xlib) and XScreenSaverSuspend (from the X11 Screen Saver extension). None of these actually work. On modern desktop Linux, we are expected to make dbus calls using some freedesktop-defined protocol (and possibly we'd have to fallback to a Gnome specific one). At least xscreensaver doesn't respect the "old" APIs either. Solve this by running the xdg-screensaver script. It's a terrible, ugly piece of shit (just read the script if you disagree), but at least it appears to work everywhere. It's also simpler than involving various dbus client libraries. I hope this can replace the --heartbeat-cmd option, and maybe we could remove our own DPMS/XSS code too.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl, x11: implement icc-profile-autowm42015-01-261-0/+3
| | | | | | | | | | | | | | | | | 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: copy WinID optionwm42014-12-091-0/+1
| | | | For the purpose of making "--wid" setable at any time.
* vo/x11: implement VOCTRL_GET_DISPLAY_NAMES with xrandr names (e.g., "LVDS1")Kevin Mitchell2014-11-071-0/+1
| | | | | | | | 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-4/+0
| | | | | 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/+1
| | | | | | More or less requested by #1237. Should be simple to extend this to other backends.
* x11: if the WM supports _NET_FRAME_EXTENTS, don't wait for mapwm42014-09-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+0
|
* x11: listen to xrandr eventswm42014-08-171-0/+2
| | | | | | | | | | | 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: use xrandr to retrieve display refresh ratewm42014-08-161-0/+11
| | | | | | | | | | | | |