summaryrefslogtreecommitdiffstats
path: root/options/m_config.h
Commit message (Collapse)AuthorAgeFilesLines
* options/m_config: fix no newline at end of filenanahi2024-03-191-1/+1
|
* options: split m_config.c/hwm42020-03-131-366/+1
| | | | | | | | | | | | | | | | | Move the "old" mostly command line parsing and option management related code to m_config_frontend.c/h. Move the the code that enables other part of the player to access options to m_config_core.c/h. "frontend" is out of lack of creativity for a better name. Unfortunately, the separation isn't quite clean yet. m_config_frontend.c still references some m_config_core.c implementation details, and m_config_new() is even left in m_config_core.c for now. There some odd functions that should be removed as well (marked as "Bad functions"). Fixing these things requires more changes and will be done separately. struct m_config is left with the current name to reduce diff noise. Also, since there are a _lot_ source files that include m_config.h, add a replacement m_config.h that "redirects" to m_config_core.h.
* options: stop hiding deprecated optionswm42020-02-041-1/+0
| | | | | I think this was annoying. It shouldn't be dishonest about which options exist. List them as "[deprecated]" instead.
* command: make sub-step command actually apply sub-delay change properlywm42020-01-041-0/+4
| | | | | | | | | The change was not propagated to the OSD/subtitle code, since that still uses an "old" method. Change it so that the propagation is actually performed. (One could argue the OSD/subtitle code should use other ways to update the options, but that would probably be more effort for now.)
* player: change m_config to use new option handling mechanismswm42019-11-291-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-291-1/+2
| | | | | | 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-291-15/+4
| | | | | | | 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: allow writing options through m_config_cachewm42019-11-291-0/+14
| | | | | | | | | | | | | | 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-291-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-291-12/+4
| | | | | | | | | | 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.
* options: remove options-to-property bridgewm42019-11-251-11/+0
| | | | | | | | 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.
* 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.
* options: remove M_SETOPT_RUNTIMEwm42019-11-101-3/+0
| | | | | | | Used to contain flags for "save" setting of options at runtime. Now there is nothing special needed anymore and it's 0. So drop it completely, and remove anything that distinguishes between runtime and initialization time.
* options: remove M_OPT_FIXEDwm42019-11-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Options marked with this flag were changed to strictly read-only after initialization (mpv_initialize() in the client API, after option parsing and config file loading with the CLI player). This used to be necessary, because there was a single option struct that could be accessed by multiple threads. For example, --config-dir sets MPOpts.force_configdir, which was read whenever anything accessed the mpv config dir (which could be on different threads, e.g. font initialization tries to lookup fonts.conf from an arbitrary thread). This isn't needed anymore, because threads now access these in a thread safe way. In the case of --config-dir, the path is actually just copied on init. This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still prevents writing to some options that cannot take effect at runtime, but even that can be dropped. In general, all mpv options can be changed any time at runtime, even if they never take effect, and there's no need to make an exception for a very low number of options. So just get rid of it.
* m_config: remove m_config_create_shadowwm42019-09-191-4/+0
| | | | | | | A previous commit changed m_config so that it always creates the shadow thing, and the function's only remaining purpose was to initialize mpv_global. It makes much more sense to do that at the caller, and it's only 1 line of code too.
* m_config: move group list to internal contextwm42019-09-191-7/+0
| | | | | | | | | | This is good because a private thing is not so public anymore, and it's also preparation for further changes. Some tricky memory management issues: m_config_data (i.e. config->data) now depends on m_config_shadow, instead of m_config. In particular, free_option_data() accesses the m_config_shadow.groups array. Obviously it must be freed before m_config_shadow.
* m_config: add/move some commentswm42019-09-191-6/+33
| | | | | | | Move the comments documenting exported functions to the header. It looks like the header is the preferred place for that (although I don't really appreciate headers where you lose the overview because of all the documentation comments). Add comments to some undocumented prototypes.
* m_config: remove an unused functionwm42019-09-191-2/+0
| | | | | | | | | This was one of those "shouldn't exist" type of functions that could access internals that were supposed to be isolated away, but some code needed to access it anyway. It looks like the last use of it went away in 2016, shortly after it was introduced.
* m_config: add a special define to access main configwm42018-05-241-4/+6
| | | | | | | | Passing NULL to mp_get_config_group() returns the main option struct. This is just a dumb hack to deal with inconsistencies caused by legacy things (as I'll claim), and will probably be changed in the future. So before littering the whole code base with hard to find NULL parameters, require using callers an easy to find separate define.
* m_config: remove extra default_data fieldwm42018-05-241-1/+2
| | | | Just wastes memory (a few KB, because there are so many options).
* m_config: remove unused fieldswm42018-05-241-5/+0
|
* m_config: remove an old temporary hackwm42018-05-241-11/+13
| | | | | | | | | | | | | | | | Actually rewrite most of the option management code. This affects how options are allocated, and how thread-safe access to them is done. One thing that is nicer is that creating m_config_cache does not need to ridiculously recreate and store the entire option list again. Instead, option metadata and option storage are now separated. m_config contains the metadata, and m_config_data all or parts of the actual option values. (m_config_cache simply uses the metadata part of m_config, which is immutable after creation.) The mentioned hack was introduced in commit 1a2319f3e4cc4, and is the global state around g_group_mutex. Although it was "benign" global state, it's good that it's finally removed.
* m_config: remove outdated commentwm42018-05-241-1/+0
|
* m_config: remove an unused functionwm42018-05-241-4/+0
|
* options: simplify mp_get_config_group() memory managementwm42018-01-181-2/+0
| | | | | | | | | | | | | | | | There is some craziness here: the function allocates m_config_cache, which in turn allocates the actual option struct, which is what the function returns. The user would expect to be able to use talloc_free() to deallocate everything. Of course this didn't work, because the returned pointer is not the root parent in the talloc tree. But with some additional talloc craziness, this can be fixed. We rearrange the parent pointers such that freeing the option struct will free m_config_cache first, which uninits the contents in the option struct, but fortunately not the option struct itself. This change should simplify API use on the caller side, and reduce surprises.
* audio: add global options for resampler defaultswm42018-01-131-3/+0
| | | | | | | | This is part of trying to get rid of --af-defaults, and the af resample filter. It requires a complicated mechanism to set the defaults on the resample filter for backwards compatibility.
* options: move most subtitle and OSD rendering options to sub structswm42018-01-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove them from the big MPOpts struct and move them to their sub structs. In the places where their fields are used, create a private copy of the structs, instead of accessing the semi-deprecated global option struct instance (mpv_global.opts) directly. This actually makes accessing these options finally thread-safe. They weren't even if they should have for years. (Including some potential for undefined behavior when e.g. the OSD font was changed at runtime.) This is mostly transparent. All options get moved around, but most users of the options just need to access a different struct (changing sd.opts to a different type changes a lot of uses, for example). One thing which has to be considered and could cause potential regressions is that the new option copies must be explicitly updated. sub_update_opts() takes care of this for example. Another thing is that writing to the option structs manually won't work, because the changes won't be propagated to other copies. Apparently the only affected case is the implementation of the sub-step command, which tries to change sub_delay. Handle this one explicitly (osd_changed() doesn't need to be called anymore, because changing the option triggers UPDATE_OSD, and updates the OSD as a consequence). The way the option value is propagated is rather hacky, but for now this will do.
* options: add a thread-safe way to notify option updateswm42017-08-221-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far, we had a thread-safe way to read options, but no option update notification mechanism. Everything was funneled though the main thread's central mp_option_change_callback() function. For example, if the panscan options were changed, the function called vo_control() with VOCTRL_SET_PANSCAN to manually notify the VO thread of updates. This worked, but's pretty inconvenient. Most of these problems come from the fact that MPlayer was written as a single-threaded program. This commit works towards a more flexible mechanism. It adds an update callback to m_config_cache (the thing that is already used for thread-safe access of global options). This alone would still be rather inconvenient, at least in context of VOs. Add another mechanism on top of it that uses mp_dispatch_queue, and takes care of some annoying synchronization issues. We extend mp_dispatch_queue itself to make this easier and slightly more efficient. As a first application, use this to reimplement certain VO scaling and renderer options. The update_opts() function translates these to the "old" VOCTRLs, though. An annoyingly subtle issue is that m_config_cache's destructor now releases pending notifications, and must be released before the associated dispatch queue. Otherwise, it could happen that option updates during e.g. VO destruction queue or run stale entries, which is not expected. Rather untested. The singly-linked list code in dispatch.c is probably buggy, and I bet some aspects about synchronization are not entirely sane.
* m_option: remove redundant indirectionswm42017-07-021-20/+1
| | | | | | Remove the various redundant m_config_set_option* calls, rename the remaining one to m_config_set_option_cli(), and merge the m_config_parse_option() function.
* options: change license of most files to LGPL (except options.c/.h)wm42017-06-121-7/+7
| | | | | | | | | | | | | | | | | | | | | | | All authors of the current code have agreed (as far as this commit requires). options.c/options.h will take more effort, because it contains all the option declarations, and thus is touched extremely often. m_option.c is technically still GPL, because of commit 2c82d5a1d85378dd0 (michael has agreed to LGPL, but only once the core of mpv is LGPL). The geometry parsing code in m_option.c was originally by someone who could not be reached. However, it was heavily rewritten anyway, and only the syntax remains (i.e. not copyright-relevant). parse_commandline.c contains a change by "adland" (commit 1d0ac71ae8ba), who could not be reached - this this specific part is GPL only. Fortunately, it matters only for DVD (and even then is more like a hack, but whatever). There are some other relevant changes, but they have all been reverted, moved somewhere else, deleted, or replaced.
* options: remove deprecated sub-option handling for --vo and --aowm42016-11-251-0/+3
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* options: remove legacy global sub-option syntaxwm42016-11-221-6/+0
| | | | | | A bit of sanity, although a very small one. --vo sub-options are not affected by this yet.
* player: do not let pseudo-gui override user config settingswm42016-09-231-0/+2
| | | | | | | | Seems like this confused users quite often. Instead of --profile=pseudo-gui, --player-operation-mode=pseudo-gui now has to be used to invoke pseudo GUI mode. The old way still works, and still behaves in the old way.
* m_config, command: remove some minor code duplicationwm42016-09-231-0/+2
| | | | | | I would have been fine with this, but now I want to add another flag, and the duplication would become more messy than having a strange function for deduplication.
* options: slightly better option update mechanismwm42016-09-191-0/+7
| | | | | | | | | | | | | | Extend the flag-based notification mechanism that was used via M_OPT_TERM. Make the vo_opengl update mechanism use this (which, btw., also fixes compilation with OpenGL renderers forcibly disabled). While this adds a 3rd mechanism and just seems to further the chaos, I'd rather have a very simple mechanism now, than actually furthering the mess by mixing old and new update mechanisms. In particular, we'll be able to remove quite some property implementations, and replace them with much simpler update handling. The new update mechanism can also more easily refactored once we have a final mechanism that handles everything in an uniform way.
* player: more option/property consistency fixeswm42016-09-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some properties had a different type from their equivalent options (such as mute, volume, deinterlace, edition). This wasn't really sane, as raw option values should be always within their bounds. On the other hand, these properties use a different type to reflect runtime limits (such as range of available editions), or simply to improve the "UI" (you don't want to cycle throuhg the completely useless "auto" value when cycling the "mute" property). Handle this by making them always return the option type, but also allowing them to provide a "constricted" type, which is used for UI purposes. All M_PROPERTY_GET_CONSTRICTED_TYPE changes are related to this. One consequence is that you can set the volume property to arbitrary high values just like with the --volume option, but using the "add" command it still restricts it to the --volume-max range. Also deprecate --chapter, as it is grossly incompatible to the chapter property. We pondered renaming it to --chapters, or introducing a more powerful --range option, but concluded that --start --end is actually enough. These changes appear to take care of the last gross property/option incompatibilities, although there might still be a few lurking.
* options: take care of propertly updating options on runtime changeswm42016-09-171-2/+8
| | | | | | | | | | | | | | | | | | | | | | All option write accesses are now put through the property interface, which means runtime option value verification and runtime updates are applied. This is done even for command line arguments and config files. This has many subtle and not-so-subtle consequences. The potential for unintended and intended subtle or not-subtle behavior changes is very large. Architecturally, this is us literally jumping through hoops. It really should work the other way around, with options being able to have callbacks for value verification and applying runtime updates. But this would require rewriting the entirety of command.c. This change is more practical, and if anything will at least allow incremental changes. Some options are too incompatible for this to work - these are excluded with an explicit blacklist. This change fixes many issues caused by the mismatch between properties and options. For example, this fixes #3281.
* options: make --h list options according to a pattern passed to itwm42016-09-101-4/+1
| | | | | | Useless feature, but I want it. Won't work on Windows due to missing fnmatch().
* m_config: remove another unused leftoverwm42016-09-101-3/+0
|
* stream, demux, config: remove some dead/unneeded option-related codewm42016-09-091-9/+0
| | | | | | | | | | This has all been made unnecessary recently. The change not to copy the global option struct in particular can be made because now nothing accesses the global options anymore in the demux and stream layers. Some code that was accidentally added/changed in commit 5e30e7a0 is also removed, because it was simply committed accidentally, and was never used.
* config: allow profile forward-references in default profilewm42016-09-021-0/+4
| | | | | | | | This works by first parsing a config file into the default profile, and applying it once parsing the whole file is finished. This won't work across config files (not even if you include other config files via "include=file.conf").
* vo_opengl: deprecate sub-options, add them as global optionswm42016-09-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
* m_config: add some convenience functionswm42016-09-021-0/+14
| | | | To be used by the following commits.
* m_config: introduce basic mechanism to synchronize global option updateswm42016-09-021-0/+54
| | | | | | | | | | | | | | | | | | The way option runtime changes are handled is pretty bad in the current codebase. There's a big option struct (MPOpts), which contains almost everything, and for which no synchronization mechanism exists. This was handled by either making some options read-only after initialization, duplicating the option struct, using sub-options (in the VO), and so on. Introduce a mechanism that creates a copy of the global options (or parts of it), and provides a well-defined way to update them in a thread-safe way. Most code can remain the same, just that all the component glue code has to explicitly make use of it first. There is still lots of room for improvement. For example, the update mechanism could be better.
* m_config: add helper function for initializing af/ao/vf/vo suboptionswm42016-09-021-6/+3
| | | | | | | | Normally I'd prefer a bunch of smaller functions with fewer parameters over a single function with a lot of parameters. But future changes will require messing with the parameters in a slightly more complex way, so a combined function will be needed anyway. The now-unused "global" parameter is required for later as well.
* command: add options to property listwm42016-09-011-1/+4
| | | | | | | | | | | Now options are accessible through the property list as well, which unifies them to a degree. Not all options support runtime changes (meaning affected components need to be restarted for the options to take effects). Remove from the manpage those properties which are cleanly mapped to options anyway. From the user-perspective they're just options available through the property interface.
*