Previously, using m_option_type_alias required that the alias have the
full name of the option value. This is limited if you are reusing the
same opts struct in different sub options. Fix this by add an additional
field to m_option to signal whether or not prefixes should be taken into
account for the alias option. Instead of blindly using whatever is
stored in opt->priv as the name, we can construct the desired option
name for either case (using the prefix or not).
bc28f7693d originally added this, but the
implementation isn't correct and causes excessive notifications when
writing to other options which may have bad behavior in some some
circumstances. Fix this by reworking the implementation for force
options so that the timestamps of the option update compared instead.
Whenever an option gets changed, the internal timestamp in the cache is
always incremented. For a special force option, we can save this
timestamp internally as well.
Because cache_check_update is always checked before potentially sending
an option notification, we know that if the internal timestamp is equal
to the timestamp saved by a force update option, it must have been
previously written. Thus, the notification can be sent. This lets
options like geometry work repeatedly but without constantly sending
notifications. Fixes#13954.
mpv's core does not propagate option notifications unless they actually
change to the rest of the player. Most of the time, this makes perfect
sense. If the user sets fullscreen multiple times, there's no reason to
care about anything other than the change in state. However, there are
certain options where it makes sense to always broadcast a notification
even if the value doesn't change. For example, consider the window-scale
case. A user may set window-scale to some value, resize the window
further through some other means (such as mouse resizing) and then want
to set the window-scale again to the same value as earlier. The
window-scale value did not change from before so no notification is sent
and nothing happens even though it is desirable and expected that it
operates again.
This was solved by making the current-window-scale property writable a
few years ago, but actually the easier solution is to just always force
the option to update on any write. For the big callback, the needed
changes are trivial. Unfortunately, it requires a hot mess in order to
have this work with the m_config_cache_update APIs. Spooky stuff in
there, but it does send the notification now.
C standard says that `= {0}` activates and initializes first member of
union. We expect whole union to be zeroed, it is used as default value.
Initialize union with one zeroed default instance to ensure proper init.
Fixes: #12711
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
This seems to work on gcc, clang and mingw as-is, but I made it
conditional on __GNUC__ just in case, even though I can't figure out
which compilers we care about that don't export this define.
Also replace all instances of assert(0) in the code by MP_UNREACHABLE(),
which is a strict improvement.
Try to remove m_config implementation details from m_config_frontend.
Not sure if I like it. Seems to be ~100 lines of awkward code more, and
not much is gained from it. Also it took way too long to do it, and
there might be bugs.
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.
Dudemanguy
Kacper Michajłow
NRK
Niklas Haas
wm4