summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* x11: update --geometry at runtime and react to runtime option changesx11_geowm42019-11-304-1/+55
| | | | Not sure if I want this.
* vo_gpu: opengl: add hack for ancient Mesa/GLXwm42019-11-301-23/+47
| | | | | | | | | | | | | | | | glx.h recursively includes gl.h, and there is no way to prevent this. Old Mesa defines some GL symbols, but not all which mpv needs. In particular, one user who was too lazy to update his ancient Ubuntu and preferred to bother us with obscure bug reports, had Mesa headers which did not define GL 3.2, so GLsync was not defined. All in all I still think the idea of providing the GL API definitions ourselves was a good idea; just GLX should have been isolated better. But isolating GLX now is too much effort. Not sure why I'm bothering with this at all. Fixes: #7201 (unconfirmed)
* osc: ensure the window-controls mouse area is initially zero sizedPhilip Langdale2019-11-301-0/+1
| | | | | | This is necessary to avoid breaking input behaviour in the 'idle' state when not playing a video. Otherwise, the mouse area starts off covering the whole window and blocks normal input.
* js: mp.add_key_binding: allow false-y name (match 311cc5b)Avi Halachmi (:avih)2019-11-301-1/+3
| | | | | This is in addition to the allowed omission of name and/or flags (as documented).
* lua: unbreak mp.add_key_binding(key, fn)Avi Halachmi (:avih)2019-11-301-1/+1
| | | | | | | Commit 311cc5b6 added the ability use flags while omitting name, but broke the case where both name and flags are omitted. Now omitting either name or flags or both works as documented.
* osc: fix typo wsc_geo -> wc_geoPhilip Langdale2019-11-301-1/+1
|
* osc: apply boxvideo margins to the window controlsPhilip Langdale2019-11-302-1/+6
| | | | | | It seems logical to account for the window controls if `boxvideo` is in use (which has the effect of reducing the size of the video so that the osc is not covering the video).
* filters: fix incorrect #if for vf_gpuwm42019-11-301-1/+1
| | | | | | | This didn't match what is in wscript_build.py. Also, it should work on non-X11 platforms... probably. (The condition is convoluted and almost nonsensical, but the offscreen context creation needs to be cleaned up anyway as soon as other backends, e.g. for win32, are added.)
* command: remove property change notification from property dispatcherwm42019-11-301-3/+2
| | | | | | Properties should handle this themselves. This basically sent redundant notifications. I found only two places where the "proper" notification was missing.
* command: merge two functionswm42019-11-301-11/+3
| | | | Due to recent changes, it makes no sense anymore to keep them separate.
* command: remove another unneeded hackwm42019-11-301-12/+2
| | | | | | | | | | | Now that the option-to-property bridge is gone, this is not needed anymore. It always took the "silent" path. Also, at least as of before this commit, this didn't correctly print a warning when accessing a deprecated option as property. This was because m_config_get_co_raw() was used, which intentionally does not print any warnings, so switch to the non-raw one. (Affects only options that have .deprecation_message set.)
* vf_gpu: add video filter using vo_gpu's rendererwm42019-11-295-0/+405
| | | | | | | | | Probably pretty useless in this form (see: the wall of warnings), but someone wanted this. I think this should be useful to perform some automated tests, maybe. Fixes: #7194
* vo_gpu: opengl: do not free "GL" sub-allocationswm42019-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | This function always expects the GL struct pointer to be a talloc allocation. So far so bad. But the terrible thing is that _lots_ of code in mpv didn't quite get this (including the code which introduced the way it is used this way). For example, in context_glx.c you see this: struct priv { GL gl; ... GL is not a talloc allocation, but since it's at the start of a talloc allocation, it works anyway. So far so bad. But the really terrible thing is that mpgl_load_functions2() calls talloc_free_children() on the GL pointer, which means that all of priv's. This would be unintentional and could create dangling pointers. And this happens at the about 1 dozen of callers. I'm amazed it didn't broke yet anywhere. Removing this anti-pattern with making GL "implicitly" a talloc allocation would be too much effort at this point. So just manually free the only allocation that the function attached to GL.
* osc: fix operation when window controls are disabledwm42019-11-291-2/+4
| | | | | It seems this area is simply not defined when window controls are disabled, so ipairs() will crash on it.
* x11: implement unminimizationwm42019-11-292-2/+6
| | | | This appears to work with IceWM.
* osc: handle deadzone and barmargin for window controlsPhilip Langdale2019-11-291-6/+28
| | | | | | | | | | | | | | | | I missed these due to only testing with my personal osc config. The deadzone needs to be correctly handled for the window controls, or they will fail to appear when the mouse is close to or over them. In the process of doing that, I realised that the controls should respect the barmargin, if set. This is because the controls should remain aligned when layout=topbar and as the control bar is top aligned, it should be equally affected if the user needs to set the barmargin. I also fixed a mistake in trying to the use the mpv-osd-symbols font for the window controls.
* 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).
* command: change window-minimized/window-maximized to optionswm42019-11-296-64/+28
| | | | | Unfortunately, this breaks window state reporting for all VOs which supported it. This can be fixed later (for x11 in the next commit).
* 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-294-14/+24
| | | | | | | | | | | | | | | - 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)
* player: change m_config to use new option handling mechanismswm42019-11-297-86/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of making m_config a special-case, it more or less uses the underlying m_config_cache/m_config_shadow APIs properly. This makes the player core a (relatively) equivalent user of the core option API. In particular, this means that other threads can change core options with m_config_cache_write_opt() calls (before this commit, this merely led to diverging option values). An important change is that before this commit, mpctx->opts contained the "master copy" of all option data. Now it's just another copy of the option data, and the shadow copy is considered the master. This is why whenever mpctx->opts is written, the change needs to be copied to the master (thus why this commits add a bunch of m_config_notify... calls). If another thread (e.g. a VO) changes an option, async_change_cb is now invoked, which funnels the change notification through the player's layers. The new self_notification parameter on mp_option_change_callback is so that m_config_notify... doesn't trigger recursion, and it's used in cases where the change was already "processed". It's still needed to trigger libmpv property updates. (I considered using an extra m_config_cache for that, but it'd only cause problems with no advantages.) I think the recent changes actually forgot to send libmpv property updates in some cases. This should fix this anyway. In some cases, property updates are reworked, and the potential for bugs should be lower (probably). The primary point of this change is to allow external updates, for example by a VO writing the fullscreen option if the window state is changed by the window manager (rather than mpv changing it). This is not used yet, but the following commits will.
* m_config: make m_config_cache_write_opt() check/return changeswm42019-11-292-8/+14
| | | | | | Goes in line with the recent changes to always checking for option value changes. The player core will use this to determine whether it should send additional change events.
* options: get rid of GLOBAL_CONFIG hackwm42019-11-2910-43/+34
| | | | | | | Just an implementation detail that can be cleaned up now. Internally, m_config maintains a tree of m_sub_options structs, except for the root it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to it anyway. Define it explicitly instead.
* m_config: untangle new and old code somewhatwm42019-11-291-75/+177
| | | | | | | | | | | | | | The original MPlayer m_config was essentially only responsible for handling some command line parsing details, handling profiles, and file-local options. And then there's the new mpv stuff (that stuff was regretfully written by me), which is mostly associated with making things thread-safe (includes things like making it all library-safe, instead of stuffing all option data into global variables). This commit tries to separate them some more. For example, m_config_shadow (the thread-safe thing) now does not need access to m_config anymore. m_config can hopefully be reduced to handling only the "old" mplayer-derived mechanisms.
* m_config: allow writing options through m_config_cachewm42019-11-292-0/+74
| | | | | | | | | | | | | | This will allow any other threads to write to the global option data in a safe way. The typical example for this is the fullscreen option, which needs to be written by VO (or even some other thing running completely separate from the main thread). We have a complicated and annoying contraption which gets the value updated on the main thread, and this function will help get rid of it. As of this commit, this doesn't really work yet, because he main thread uses its own weird copy of the option data.
* m_config: add fine-grained option reporting mechanismwm42019-11-292-34/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds m_config_cache_get_next_changed() and the change_flags field in m_config_cache. Both can be used to determine whether specific options changed (rather than the entire sub-group). Not sure if I'm very happy with that. The former rather compact update_options() is now a bit of a mess, because it needs to be incremental. m_config_cache_get_next_changed() will not be too nice to use, and change_flags still relies on global "allocation" of change flags (see UPDATE_* defines in m_option.h). If C weren't such a primitive language that smells like grandpa, it would be nice to define per-option change callbacks or so. This compares options by value to determine whether they have changed. This makes it slower in theory, but in practice it probably doesn't matter (options are rarely changed after initialization). The alternative would have been per-option change counters (wastes too much memory; not a practical problem but too ugly), or keep all m_config_caches in a global list and have bitmaps with per-option change bits (sounds complicated). I guess the current way is OK. Technically, this changes semantics slightly by ignoring setting an option to the same value. Technically this wasn't a no-op, although the effect was almost almost no-op. Some code would actually become cleaner by ignoring such redundant change events, and them being no-op is probably also what the user would normally assume.
* m_config: move stuff aroundwm42019-11-292-53/+77
| | | | | | | | | | Create a separate struct for internal fields of m_config_cache, so API users can't just mess with stuff they shouldn't access. Move the ts field out of m_config_data, so we don't need unnecessary atomics in one case. This is just preparation, and shouldn't change any behavior.
* atomic: add mp_atomic_uint64wm42019-11-291-0/+2
|
* m_option: remove an outdated ancient commentwm42019-11-291-7/+1
| | | | | | | The exact type name (m_obj_list_t) was removed in 2013. I don't think this stub comment helps much with understanding this complicated thing anyway (this code is for the --vf/--af options, and makes up almost half of m_option.c).
* f_output_chain: use m_option_equal()wm42019-11-291-30/+3
| | | | | | | | | This is used to detect whether any filters were changed. This code was essentially ported to m_option.c. One possible difference is how the old code did name comparison. It did not actually compare the name (!?!?), so this might change behavior, hopefully to the better.
* command: use m_option_equal()wm42019-11-291-16/+1
| | | | No more converting the option values to a string to compare it.
* m_option: add option comparisonwm42019-11-292-1/+156
| | | | | | Looks like this will be needed for fine-grained option change notifications. There are some other parts in the player which implement parts of this.
* man/osc: fix typoPhilip Langdale2019-11-291-1/+1
|
* x11: implement minimize and maximize related VOCTRLsPhilip Langdale2019-11-292-2/+49
| | | | | This allows the pseudo client side decorations to be used under x11, which might be desirable when running in border=no mode.
* osc: implement pseudo client side decorations via OSCPhilip Langdale2019-11-292-7/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, if window decorations are not present, either because they were disabled, or because the platform doesn't support them (eg: gnome-shell on wayland), there are no window controls, meaning it is not possible to minimize/maximize/close a window without knowing keyboard shortcuts. While you can imagine various ways of offering client side decorations, it is attractive to consider using OSC because that is functionality that we already have. The main work here is defining a separate input area from the main OSC box with its own buttons, etc. While we could probably handle auto-detection based on whether decorations are present or not, it's manually controlled for now. The window control logic is mostly disconnected from the OSC itself, except in the case of the `topbar` layout, where there has to be coordination so that the controls don't get drawn on top of each other. I had to do fine-positioning of the buttons based on the font on my system, so don't be surprised if it looks wrong elsewhere. You could also argue that window controls should be unscaled, even if the main OSC box is scaled, but I've not tried to do this.
* wayland: implement minimize and maximize related VOCTRLsPhilip Langdale2019-11-291-0/+27
| | | | | | | We primarily care about pseudo-decorations for wayland, where the compositor may not support server-side decorations. So let's implement the minimize and maximize commands and return the maximized window state.
* command: add `window-maximized` and make `window-minimized` settablePhilip Langdale2019-11-292-3/+43
| | | | | | | | | | | If we want to implement window pseudo-decorations via OSC, we need a way to tell the vo to minimize and maximize the window. Today, we have minimized as a read-only property, and no property for maximized. Let's made minimized settable and add a maximized property to go with it. In turn, that requires us to add VOCTRLs for minimizing or maximizing a window, and an additional WIN_STATE to indicate a maximized window.
* wayland: restore window geometry after un-maximizePhilip Langdale2019-11-291-3/+2
| | | | | | | | | | | | | At least with gnome-shell (I know, I know), the compositor does not provide the old window size when leaving the maximized state. Instead, we get a toplevel_config event with a 0x0 size and no additional states. Today, we already save the window geometry to restore it when leaving the fullscreen state, so we just need a small change for it to kick in for leaving the maximized state. If I read this correctly, we'll still respect the size passed by a compositor that actually provides the old size.
* wayland: make the edge grab zone width user configurablePhilip Langdale2019-11-292-5/+8
| | | | | | | Rather than hard-coding the edge grab zone width, we can make it user configurable. It seems worthwhile to have separate configs for pointer and touch usage as the defaults should be different, and a user might have both input methods in use.
* wayland: add grab zone for resizing window with mousePhilip Langdale2019-11-292-40/+54
| | | | | | | | Today, we support resizing wayland windows when we detect a touch event in a defined grab zone. As part of implementing pseudo-decorations, we should have equivalent functionality for mouse input. And if we detect support for actual decorations we will not activate the grab zone as the decorations will provide this.
* DOCS/interface-changes.rst: more details about track property changeswm42019-11-271-1/+4
| | | | | Another subtle thing that should be mentioned. May or may not matter to someone.
* x11_common: don't use vo->opts directlywm42019-11-272-25/+26
| | | | | | | | | 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.
* options: remove options-to-property bridgewm42019-11-256-85/+6
| | | | | | | | The previous bunch of commits made this unnecessary, so this should be a purely internal change with no user impact. This may or may not open the way to future improvements. Even if not, at least the property/option interaction should now be much less buggy.
* command: shuffle around even more crapwm42019-11-252-79/+23
| | | | | | | | | | | | | | | | | | Convert some remaining properties to work without the option-to-property bridge. Behavior shouldn't change (except for the corner case that it tries to reapply the new state when setting a property, while it used to ignore redundant sets). As it is the case with many of these changes, much of the code is not in its final proper state yet, but is rather a temporary workaround. For example, these "VO flag" properties should just be fully handled in the VO backend. (Currently, the config or VO layers don't provide enough mechanism yet as that all the backends like x11, win32, etc. could be changed yet, but that's another refactoring mess for another time.) Now nothing relies on this option-to-property bridge anymore, which opens the way to even more refactoring, which eventually may result in tiny improvements for the end user.
* command: change vid/aid/sid property behavior slightlywm42019-11-253-48/+35
| | | | | Again in line with the option-to-property bridge changes. As usual, this causes subtle behavior changes, which may affect some users.
* options: pre-check filter names when using vf/af libavfilter bridgewm42019-11-255-1/+29
| | | | | | | | | | | | | Until now, using a filter not in mpv's builtin filter list would assume it's a libavfilter filter. If it wasn't, the option value was still accepted, but creating the filter simply failed. But since this happens after option parsing, so the result is confusing. Improve this slightly by checking filter names. This will reject truly unknown filters at option parsing time. Unfortunately, this still does not check filter arguments. This would be much more complex, because you'd have to create a dummy filter graph and allocate the filter. Maybe another time.
* command: change af/vf property behavior wrt. filter creation failureswm42019-11-253-12/+19
| | | | | | The behavior is slightly different in a messy way. The change is in line with the option-to-property bridge removal mentioned some commits ago and thus is deemed necessary.
* command: remove redundant reinit_filters() call on filter change failurewm42019-11-251-1/+0
| | | | | | This attempted to restore the old filter chain if setting a new one at runtime failed. This is not needed anymore, because changing the filter chain is done in a "transactional" way now.
* f_output_chain: fix possible crash when changing filterswm42019-11-251-2/+4
| | | | | | When changing filters at runtime (vf/af commands/properties), this could crash due to a NULL pointer access. The code for comparing the old and new option values (to detect changes) was simply buggy.
* m_config: discourage mp_read_option_raw()wm42019-11-251-0/+1
| | | | | | This function is dangerous, because it disables the already basic/week type checking the option system has at all. I'm tend towards thinking that all of its uses should be replaced.
* command, options: deprecate old --display-fps behaviorwm42019-11-255-9/+40
| | | | | | | See changelog and manpage changes. (So much effort to fix an ancient dumb mistake for an option nobody should use anyway.)
* command: shuffle some crap aroundwm42019-11-256-170/+109
| | | | | | | | | | | | | | | | | | | | | | | | This is preparation to get rid of the option-to-property bridge (mp_on_set_option). This is a pretty insane thing that redirects accesses to options to properties. It was needed in the ever ongoing transition from something to... something else. A good example for the need of this bridge is applying profiles at runtime. This obviously goes through the config parser, but should also make all changes effective, for which traditionally the property layer is used. There isn't much left that needs this bridge. This commit changes a bunch of options (which also have a property implementation) to use option change notifications instead. Many of the properties are still left, but perform unrelated functions like OSD formatting. This should be mostly compatible. There may be some subtle behavior changes. For example, "hwdec" and "record-file" do not check for changes anymore before applying them, so writing the current value to them suddenly does something, while it was ignored before. DVB changes untested, but should work.
* manpage: remove audio-file etc. caveat descriptionwm42019-11-241-13/+0
| | | | | | | These properties actually were removed/replaced, so there is no conflict with the options of the same name anymore. For example, there is no "audio-file" property anymore, but you still can set "audio-fi