summaryrefslogtreecommitdiffstats
path: root/video/out/x11_common.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | On x11, you can change the fullscreen via the window manager and without mpv's involvement. In these cases, the internal fullscreen flag has to be updated. The hack used for this didn't really work properly. Change it accordingly. The important thing is that the shadow copy of the option is updated. This is still not really ideal. Fixes #3570.
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+0
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* vo: use new option update mechanismwm42016-09-021-0/+13
| | | | | | | | | | | | | | | | This is still rather basic. run_reconfig() and run_control() update the options because it's needed for panscan (and other video scaling options), and fullscreen, border, ontop updates. In the old model, these options could be accessed only while both playback thread and VO threads were locked (i.e. during synchronous calls like vo_control()), so this should be sufficient in order not to miss any updates. In the future, a more fine-grained update mechanism could be added to handle these updates "exactly". x11_common.c contains an evil hack, as I see no reasonable way to handle this properly. The VO thread can't "lock" the main thread, so this is not simple.
* vo: change messy handling of fullscreen and other flagswm42016-08-301-4/+0
| | | | | | | | | | | | | | Before this commit, all VOs had to toggle the option flag themselves, now command.c does it. I can't really comprehend why it required every VO to do this manually. Maybe it was for rejecting the property/option change if the VO didn't support a specific capability. But then it could have checked the VOCTRL result. In any case, I don't care, and successfully changing the property without doing anything (With some VOs) is fine too. Many things work this way now, and it's simpler overall. This change will be useful for cleaning up VO option handling.
* x11, wayland: always round up wait timeswm42016-08-261-1/+1
| | | | | If wait_us is >0 and <500, the wait time gets rounded down 0, effectively turning this into busy waiting. Round it up instead.
* x11: work around mutter fullscreen issuewm42016-08-251-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | If the video has the same size as the screen, starting with --fs and then leaving fullscreen doesn't actually leave fullscreen. The reason is that mpv tries to restore the previous window size if necessary (otherwise, you'd end up with a Window of nearly the same size as the screen with some WMs). It will typically restore with the rectangle set exactly to the screen if no other position or size is forced. This triggers pre-EWMH fullscreen mode, which WMs detect using various heuristics. Apparently we triggered this with mutter (but strangely no other WMs). It's possible that pre-EWMH fullscreen mode actually requires removing decorations, and mutter either ignores this. But this is speculation and I haven't checked. Work this around by reducing the requested size by 1 pixel if it happens. This was observed with mutter 3.18.2. Fixes #2072.
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-301-4/+2
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* x11: do not accidentally discard event flagswm42016-07-251-5/+4
| | | | | | | | | 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, wayland: do not accidentally close FD 0wm42016-07-211-0/+1
| | | | | | | | | | Both backends have code to close each FD of their wakeup_pipe array. This array is default-initialized with 0, which means if the backends exit before the wakeup pipe is created (e.g. when probing), they would close FD 0. Initialize the FDs with -1. Then we call close(-1) in these situations, which is perfectly allowed and has no bad consequences.
* x11: stop using vo.event_fdwm42016-07-201-1/+34
| | | | Instead let it do its own event loop wakeup handling.
* x11: skip ICC update on every window movewm42016-07-181-11/+25
| | | | | | | 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: add missing FocusChangeMaskwm42016-07-081-1/+1
| | | | | So we actually get FocusOut events. Disables key repeat when losing focus while a key is down.
* x11_common: silence xdg-screensaverBen Boeckel2016-07-051-1/+1
| | | | | Some screen lockers have a habit of dumping output to the terminal when their output is reset. Ignore its output to keep the TTY output clean.
* x11: tell GNOME to use dark window decorationsMantas Mikulėnas2016-05-091-0/+1
|
* x11: slightly safer X11 error handler behaviorwm42016-05-081-1/+4
| | | | | | | | | | | The X11 error handler is global, and not per-display. If another Xlib user exists in the process, they can conflict. In theory, it might happen that e.g. another library sets an error handler (overwriting the mpv one), and some time after mpv closes its display, restores the error handler to mpv's one. To mitigate this, check if the error log instance is actually set, instead of possibly crashing. The change in vo_x11_uninit() is mostly cosmetic.
* x11: add --x11-bypass-compositor=alwayswm42016-05-061-0/+1
| | | | Also add missing documentation for fs-only, and correct the default.
* x11: extend --x11-bypass-compositor with fs-only optionwm42016-05-021-6/+22
| | | | | | | | | | The "fs-only" choice sets the _NET_WM_BYPASS_COMPOSITOR to 1 if the window is fullscreened, and 0 otherwise. (0 is specified to be the implicit default - i.e. no change is requested in windowed mode.) In particular, change the default to "fs-only". Fixes #2582.
* x11, input: move mime type drag&drop negotiation to common codewm42016-03-151-2/+52
| | | | | | | | | | | | | Drag&drop mechanisms typically support multiple types for the drop data. Move most of the logic which types are accepted and preferred to event.c, where the data is also interpreted. (Maybe sorting the types by assigning scores is over-engineered, since they're already sorted by preference, but it's actually not much more code.) Not very interesting/meaningful yet, but preparation for the next commit.
* x11: move vo->input_ctx accesses to x11->input_ctxwm42016-03-151-19/+20
| | | | | | 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.)
* x11: stop waiting for MapNotify when WM_STATE changesTracerneo2016-01-311-1/+3
| | | | Signed-off-by: wm4 <wm4@nowhere>
* x11: get *current* XRandR screen configurationNils Schneider2016-01-201-1/+1
| | | | | |</