summaryrefslogtreecommitdiffstats
path: root/video/out/x11_common.c
Commit message (Collapse)AuthorAgeFilesLines
* x11: avoid wasteful rendering when possibleDudemanguy2022-04-111-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: fix screen-name optionDudemanguy2022-04-081-0/+1
| | | | | | | | | | | 9a7b2015e1a711a57b6e660774c36956ac59a7f6 added the --screen-name option for x11, but it was unfortunately broken. The commit does correctly handle vo_x11_update_screeninfo and select the correct screen. However, vo_x11_sizehint was missed. Specifically, the force_pos bool was always false because it only took into account --screen being set and not --screen-name. To fix this, just add an extra condition to the force_pos bool so it becomes true if there's a string in --screen_name. Fixes issue #9877.
* x11: sanitize window title to UTF-8 for EWMHDudemanguy2022-01-241-2/+7
| | | | | | | | | | Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager Hints) require that the string is UTF-8*. mpv was not doing this and thus violating the spec. Just sanitize the title for these two atoms. Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so those atoms are left the same. Fixes #8812. *: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
* player: fix autofit/geometry related segfaultDudemanguy2021-11-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Back when runtime updating of autofit/geometry was added for wayland and x11 (commits: 4445ac828dca0298543103094357e64f8828ef56 and ced92ba607ebd98687b26ef3d8c09d5f6e22cf4b respectively), the naive assumption was that window-related geometry would always be available. While this is true 99% of the time, this isn't a guarentee. It is possible for certain things such as loading shaders to delay starting up the player. This causes autofit/geometry options to be registered as a runtime update and triggers VOCTRL_VO_OPTS_CHANGED. This ends up calling some geometry-related functions but this happens before the actual values are available. Hence, a nullptr was accessed which segfaults. At least one user experienced this with a combination of options in wayland but in theory the same thing could happen under x11. The fix is simple. Just be sure to check that the required geometry is available before doing any calculations. In wayland, this would be wl->current_output. Additionally add an assert to set_geometry (we should never use this function without wl->current_output) to be extra sure. In x11, the check is on x11->window. Later when the reconfig for each backend actually happens, the autofit/geometry set by the user happens anyway so ignoring it in this case does no harm. Fixes #9381.
* x11: handle maximized windows with window-scaleDudemanguy2021-08-121-0/+6
| | | | | | | If a user attempted to change the window scale of a maximized window on x11, nothing would happen since the window manager holds the size of the window constant. Just do an unmaximize first before performing the resize.
* command: add display-width/display-height propertyDudemanguy2021-05-061-0/+7
| | | | | | | | | For some reason, this never existed before. Add VOCTRL_GET_DISPLAY_RES and use it to obtain the current display's resolution from each vo/windowing backend if applicable. Users can then access the current display resolution as display-width and display-height as per the client api. Note that macOS/cocoa was not attempted in this commit since the author has no clue how to write swift.
* x11: update geometry/autofit opts on runtimeDudemanguy2020-12-141-0/+21
| | | | | | 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: support screen-name and fs-screen-name optsDudemanguy2020-12-061-1/+19
| | | | | | | | | The --screen-name and --fs-screen-name options allow for specifying screens based on their name. For x11, this is the display name reported by xrandr. --screen-name and --fs-screen-name mimic the --screen and --fs-screen options respectively. If --screen is set, then --screen-name will always do nothing. Likewise, --fs-screen-name does nothing if --fs-screen is set.
* command: add read-only focused propertyGuido Cella2020-09-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
* x11: add option to make window appear on a specific workspacewm42020-07-121-2/+3
| | | | | | | | | Mess this into the --geometry option, because I like to be irresponsible. I considered adding a separate option, but at least this allows me to defer the question how the hell this should work as property (geometry simply and inherently does not). Tested on IceWM only. Option equality test and string output not tested.
* x11: remove terrible xdg-screensaver hackwm42020-07-081-39/+0
| | | | | | | | | | | | | | 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.
* build: change filenames of generated fileswm42020-06-041-4/+4
| | | | Force them into a more consistent naming schema.
* x11_common: added ICCCM WM_HINTSArthur Williams2020-05-241-0/+11
| | | | | | | | | | | | | | | | | | When the window is mapped, some ICCCM WM_HINTS are set. The input field is set to true and state is set to NormalState. To quote the spec, "The input field is used to communicate to the window manager the input focus model used by the client" and "[c]lients with the Passive and Locally Active models should set the input flag to True". mpv falls under the Passive Input model, since it expects keyboard input, but only listens for key events on its single, top-level window instead of subordinate windows (Locally Active) or the root window (Globally Active). From the end users prospective, all EWMH/ICCCM compliant WMs (especially the minimalistic ones) will allow the user to focus mpv, which will allow mpv to receive key events. If the input field is not set, WMs are allowed to assume that mpv doesn't require focus.
* x11: switch back to StaticGravitywm42020-02-221-4/+1
| | | | | | | | | | | | | | | | | This was changed 6 years ago (444e583b6) and seemed to work fine. But it does seem to cause issues with IceWM sometimes, while with StaticGravity the problem is gone. Comparing both gravity values, reading the confused source code comment, and reading the referenced commit message, I can't determine what it even does, I just remove it. Reproduction: - start mpv in windowed mode, with 2 videos of different size - switch to second video - switch window with alt+tab - switch back to mpv with alt+tab - window moves to X=0 There's probably a better way to fix this. Please send a patch.
* video/out/x11: add fs-screen fallbackNicolas F2019-12-221-0/+3
| | | | | | | | | | | | | Apparently there are two different options for controlling which screen an mpv window goes onto: --fs-screen and --screen. The former explicitly only controls which screen a fullscreened window goes onto, but does not appear to actually care about this option at runtime for X11, so pressing f will always fullscreen to the screen mpv is currently on. This means the option is of questionable usefulness for starters. Making it worse, if you use --screen=1 --fs, mpv will actually fullscreen on screen 0, because --fs-screen isn't set. Instead of doing that, fall back to whatever --screen is set to.
* x11: implement hidpi scale reportingwm42019-12-201-0/+3
| | | | | | | (X11 does not support different per-screen DPI (or only via hacks), so this is pretty simple. If other backends are going to implement this, then they should send VO_EVENT_WIN_STATE if the DPI for the mpv window changes by moving it to another screen or such.)
* x11: fix X property out of bounds memory readswm42019-12-181-2/+2
| | | | | | | | | | | | | | | | | | | | The size overflow check was inverted: instead of allowing reading only the first dst_size bytes of the property, it allowed copying past the property buffer (as returned by xlib). xlib doesn't return the size of the buffer in bytes, so it has to be computed and checked manually. Wouldn't it be great if C allowed me to write the overflow check in a readable way, so it doesn't trick me into writing dumb security bugs? Relying on X security is even dumber than creating a X security bug, though, so this was not a real problem. But I found that one specific call tried to read more than what the property provided, so reduce that. Also, len*ib obviously can't overflow, so there's an additional layer of dumb to this whole thing. While we're at dumb things, why the hell does xlib use "long" for 32 bit types. It's a god damn pain.
* x11: fix --hidpi-window-scale=no on hidpi screenswm42019-12-161-1/+1
| | | | | | | | | | In this combination, the [current-]window-scale properties still incorrectly applied scaling. For some reason, vo_calc_window_geometry2() handled this option (basically ignored the dpi_scale parameter passed to it), but since the DPI compensation for window-scale is implemented in x11_common.c, we need to check and honor this option here too. (What a mess.)
* x11: scale window-scale by DPIwm42019-12-161-6/+8
| | | | | | | | | | | | | | | | | "window-scale" is 1.0 by default; however, x11 implicitly set that to 2.0 on hidpi screens. This made the default 2.0, which was inconsistent with the option. The "window-scale" property jumped from 1.0 to 2.0 when a window was created. Avoid this by factoring the DPI into the window-scale. This makes the UNFS_WINDOW_SIZE return a virtual size; since this value is used for the window-scale property only, this is fine and has no further consequences. (Originally, this was possibly meant to be used for other purposes, but I'm perfectly fine with redoing this again should that ever happen.) This changes user-visible behavior, and it's as if setting window-scale multiplies its argument by 2 suddenly. Hopefully no user will get angry.
* x11: implement unminimizationwm42019-11-291-1/+5
| | | | This appears to work with IceWM.
* x11: handle maximize/minimize with new option stuffwm42019-11-291-43/+31
| | | | | | | | | Should restore full functionality. The initial state setting is a bit shoddy (instead of setting the properties before map, we use the WM commands to change it after, so you will see the normal window state for a moment; the WM commands do not work on unmapped windows, so fixing this would require more code).
* x11: add change notification for --on-all-workspaceswm42019-11-291-0/+18
| | | | | Not particularly important and nobody asked for this, but demonstrates how such things can be easily done now.
* x11: handle some more options with new option stuffwm42019-11-291-15/+14
|
* x11: use new option stuff to implement fullscreenwm42019-11-291-8/+10
| | | | | | | | | | | | | | | - 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: implement minimize and maximize related VOCTRLsPhilip Langdale2019-11-291-0/+40
| | | | | This allows the pseudo client side decorations to be used under x11, which might be desirable when running in border=no mode.
* x11_common: don't use vo->opts directlywm42019-11-271-25/+25
| | | | | | | | | 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: reduce log level for relatively uninteresting thingswm42019-11-011-9/+9
| | | | | Normally nobody cares about the WM detection stuff etc., so log this only at debug log levels.
* x11: fix ICC profiling for multiple monitorsslatchurie2019-09-211-2/+21
| | | | | | | | | 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-0/+1
| | | | | | | | | 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-19/+30
| | | | | | | I found this sort of annoying. You could argue that the "frontend" should maybe contain this logic, but who cares.
* x11: fix icc profile when the window goes near off screenslatchurie2018-10-211-1/+1
| | | | | | | | On a multi monitor setup, when the center of the window was going off screen, the icc profile would always switch to the profile of the first screen. This fixes the issue by defaulting the value to the current screen.
* x11_common: replace atoi with strtoulNicolas F2018-10-191-1/+2
| | | | | | Using strtol and strtoul is allegedly better practice, and I'm going for strtoul here because I'm pretty sure X11 displays cannot be in the negative.
* input: add a define for the number of mouse buttons and use itwm42018-05-251-0/+4
| | | | (Why the fuck are there up to 20 mouse buttons?)
* x11: support Shift+TABNiklas Haas2018-05-241-1/+1
| | | | | | | | | | | | | | For some reason, the X default modifier map binds shift+tab to ISO_Left_Tab instead of the regular Tab. So to get Shift+TAB recognized by mpv, we also need to accept ISO_Left_Tab. This patch matches what other programs like e.g. Qt do, which treat Tab and ISO_Left_Tab as the same thing. God only knows why the distinction exists, and why X decides to mix up its bindings like that. Fixes #5849
* input: merge mouse wheel and axis keycodesJames Ross-Gowan2017-09-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | Mouse wheel bindings have always been a cause of user confusion. Previously, on Wayland and macOS, precise touchpads would generate AXIS keycodes and notched mouse wheels would generate mouse button keycodes. On Windows, both types of device would generate AXIS keycodes and on X11, both types of device would generate mouse button keycodes. This made it pretty difficult for users to modify their mouse-wheel bindings, since it differed between platforms and in some cases, between devices. To make it more confusing, the keycodes used on Windows were changed in 18a45a42d524 without a deprecation period or adequate communication to users. This change aims to make mouse wheel binds less confusing. Both the mouse button and AXIS keycodes are now deprecated aliases of the new WHEEL keycodes. This will technically break input configs on Wayland and macOS that assign different commands to precise and non-precise scroll events, but this is probably uncommon (if anyone does it at all) and I think it's a fair tradeoff for finally fixing mouse wheel-related confusion on other platforms.
* input: use mnemonic names for mouse buttonsJames Ross-Gowan2017-09-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv's mouse button numbering is based on X11 button numbering, which allows for an arbitrary number of buttons and includes mouse wheel input as buttons 3-6. This button numbering was used throughout the codebase and exposed in input.conf, and it was difficult to remember which physical button each number actually referred to and which referred to the scroll wheel. In practice, PC mice only have between two and five buttons and one or two scroll wheel axes, which are more or less in the same location and have more or less the same function. This allows us to use names to refer to the buttons instead of numbers, which makes input.conf syntax a lot easier to remember. It also makes the syntax robust to changes in mpv's underlying numbering. The old MOUSE_BTNx names are still understood as deprecated aliases of the named buttons. This changes both the input.conf syntax and the MP_MOUSE_BTNx symbols in the codebase, since I think both would benefit from using names over numbers, especially since some platforms don't use X11 button numbering and handle different mouse buttons in different windowing system events. This also makes the names shorter, since otherwise they would be pretty long, and it removes the high-numbered MOUSE_BTNx_DBL names, since they weren't used. Names are the same as used in Qt: https://doc.qt.io/qt-5/qt.html#MouseButton-enum
* x11: fix that window could be resized when using embeddingwm42017-08-211-2/+5
| | | | | | | Somewhat lazy fix. The code isn't particularly robust or correct wrt. window embedding. Fixes #4784.
* Revert "x11: drop xscrnsaver use"Martin Herkt2017-08-201-0/+16
| | | | | | | | | | | | | | This broke screensaver/powersave inhibition with at least KDE and LXDE. This is a release blocker. Since fdo, KDE and GNOME idiots seem to be unable to reach a consensus on a simple protocol, this seems unlikely to get fixed upstream this year, so revert this change. Fixes #4752. Breaks #4706 but I don’t give a damn. This reverts commit 3f75b3c3439241c209349908fa190c0382e44f05.
* Revert "x11: use xdg-screensaver suspend/resume"Martin Herkt2017-08-201-60/+34
| | | | This reverts commit 6694048272619b7f91d161c040b818ff63e65279.
* x11: use xdg-screensaver suspend/resumewm42017-08-151-34/+60
| | | | | | If it doesn't work this time, I'll remove all X11 screensaver code. Fixes #4763.
* x11: drop xscrnsaver usewm42017-08-081-16/+0
| | | | | | | | | | | It's an ancient X11 protocol extension that apparently nobody uses anymore (desktop environments in particular have replaced it with equally bad protocols that require tons of dependencies). Users keep complaining about it being a required dependency. The impact is likely minimal to none. Fixes #4706 and other annoying people.
* x11: add 128x128 sized icon supportXu Zhao2017-07-021-0/+5
|
* x11: load icon differentlywm42017-07-011-83/+40
| | | | | | | | Now it's sourced from the etc/ PNG files directly, instead of preprocessing them with imagemagick. Add some ad-hoc code to decode PNG files with libavcodec. At least we can drop the zlib code in exchange.
* Avoid calling close(-1)wm42017-06-291-2/+4
| | | | | | | | | | While this is perfectly OK on Unix, it causes annoying valgrind warnings, and might be otherwise confusing to others. On Windows, the runtime can actually abort the process if this is called. push.c part taken from a patch by Pedro Pombeiro.
* build: make various x11 protocol extension libs mandatorywm42017-04-211-51/+17
| | | | | | | Reduces the ifdeffery, which is good and will avoid silent breakages, or weird behavior if a lib is omitted. Also reorder the x11_common.c include statements.
* x11: pseudo HiDPI scalingwm42017-01-191-1/+18
| | | | | | | | | | | | | | | | 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/+12
| | | | | | | | 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.)
* x11: fix external fullscreen updatewm42016-09-231-12/+4
| | | | | | | | |