There's several path-related options that do not handle common shortcuts
(like ~/). Fix this by using mp_get_user_path where appropriate which
expands the path so users get more intuitive behavior. Fixes#15598.
The libplacebo colorspace hint api makes sense for things like vulkan,
but for other APIs like drm that are capable of directly handling
colorspaces and hdr metadata it's a nuisance. Add a pass_colorspace fns
that signals to vo_gpu_next that the backend doesn't need the color
information to be manipulated and can handle the metadata itself.
libdrm unfortunately doesn't give us what is actually supported by the
connector in question. To do that, we would have to parse the edid blob.
Use libdisplay-info to do this and make it required for drm support.
Using what we get back from the library, we can do a bit of sanity
checking for hdr metadata to make sure that the display in question can
handle it before we try setting the metadata. Strictly speaking,
libdisplay-info has stuff for dynamic metadata that we could potentially
use, but as a first pass and for simplicity, only static is considered
for now.
As the first aligned format this required a fix to reconfig().
Adding the other component-swapped formats in this group would be trivial
but I checked the DRM database [1] and no driver exists that supports
one of those but not YUYV and this is quite fringe as-is, so I opted not to.
[1] <https://drmdb.emersion.fr/formats>
The opt validator functions are casted to generic validator, which has
erased type for value. Calling function by pointer of different
definition is an UB.
Avoid that by generating wrapper function that does proper argument type
conversion and calls validator function. Type erased functions have
mangled type in the name.
Fixes UBSAN failures on Clang 17, which enabled fsanitize=function by
default.
Fixes a899e14b which changed clamp from 0 to 1 ms which effectivelly
introduced 1ms sleep always, even if requested until_time_ns is in the
past and should request 0 timeout.
While at it also fix mp_poll wrapper to respect negative timeout which
should mean infinite wait.
Also keep the 37d6604 behaviour for very short timeouts, but round only
the ones > 100us, anything else is 0.
Fixes: a899e14b
This was specifically special logic for drm. Before present_sync, it
would also clear out all of its vsync values like this. The old drm code
would save a bunch of samples which would confuse vo.c when unpausing
since it got old, bogus values. Since we make sure to match successive
vsync samples with the swapchain depth and that present sync samples
also match the swapchain depth, this is unneeded.
A ton of code and drm-specific abstractions can be dropped with this.
One important thing to note is that the usage of sbc is completely
dropped here. The utility of that is not particularly clear since the
sbc value was manually incremented before the flip and it's not as if
the drm page flip event gives it to us like it does with the msec and
ust. It can be reintroduced later if there is a need. For drm, we also
add a present_sync_clear_values helper since all presentation feedback
needs to be cleared on pause/resume for it.
On linux, several platforms poll for events over a fd. This has ms
accuracy, but mpv's timer is in ns now so lots of precision is lost. We
can use an mp_poll wrapper to use ppoll instead which takes a timespec
directly with nanosecond precision. On systems without ppoll this falls
back to old poll behavior. On wayland, we don't actually use this
because ppoll completely messes up the event loop for some unknown
reason.
In many cases, this is purely cosmetic because poll still only accepts
microseconds. There's still a gain here however since
pthread_cond_timedwait can take a realtime ts now.
Additionally, 37d6604d70 changed the value
added to timeout_ms in X11 and Wayland to ensure that it would never be
0 and rounded up. This was both incomplete, several other parts of the
player have this same problem like drm, and not really needed. Instead
the MPCLAMP is just adjusted to have a min of 1.
We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting
around in the code. This is harmless, but the vast majority of these are
ancient. 26f4f18c06 is the last commit
that touched the majority of these and of course that only changed how
options were declared so all of this stuff was deprecated even before
that. No use in keeping these, so just delete them all. As an aside,
there was actually a cocoa_opts but it had only a single option which
was replaced by something else and empty otherwise. So that entire thing
was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were
added in 0.35 or later were kept as is.
It's possible for systems to have multiple cards, and the first capable
card to not have a connected output. Skip such cards and continue
iterating until we find one with a connected output.
A longstanding pain point of the drm VOs is the relative lack of state
sharing. While drm_common does provide some sharing, it's far less than
other platforms like x11 or wayland. What we do here is essentially copy
them by creating a new vo_drm_state struct and using it in vo_drm and
context_drm_egl. Much of the functionality that was essentially
duplicated in both VOs/contexts is now reduced simple functions in
drm_common. The usage of the term 'kms' was also mostly eliminated since
this is libdrm nowadays from a userspace perspective.
The legacy DRM API adds some complexity to the DRM code. There
are only 4 drivers that do not support the DRM Atomic API:
1. radeon (early GCN amd cards)
2. gma500 (ancient intel GPUs)
3. ast (ASPEED SoCs)
4. nouveau
Going forward, new DRM drivers will be guaranteed to support the atomic
API so this is a safe removal.
ae768a1e14 forgot to bump the required
libdrm version however Debian 11 just barely misses the requirement,
which is a good reason not to require it unconditionally anyway.
Avoids another pitfall on systems where the first card has a primary
node but is not capable of KMS. With this change --drm-context=drm
should work correctly out-of-the-box in all cases.
So it turns out that mpv already has an mp_tag_str which makes a
readable string out of fourccs (drm formats are these).
drm_format_string, on the other hand, has a ton of baggage with having
to check different libdrm versions for certain headers, adding
compile-time defines (because there are no version defines in the libdrm
headers), etc. It's a lot simpler to just use what mpv already has and
it returns what you actually care about: i.e. is this format supported
or not. Fixes https://github.com/mpv-player/mpv-build/issues/184
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used
with DRM by setting the VRR_ENABLED property on a crtc if the
connector reports that it is VRR_CAPABLE. This is a useful feature
for us as it is common to play 24/25/50 fps content on displays that
are nominally locked to 60Hz. VRR can allow this content to play at
native framerates.
This is a simple change as we just need to check the capability
and set the enabled property if requested by the user. I've defaulted
it to disabled for now, but it might make sense to default to auto
in the long term.
The new GBM supporting nvidia drivers declare support for 10bit
surfaces using BGR ordering, rather than RGB, so add support for them.
We've also seen examples of hardware supporting BGR8888 but not
RGB8888 so let's support those too.
Of course, the nvidia EGL driver doesn't publish support for any 10bit
formats so you can't actually do 10bit display. Perhaps they'll
eventually fix that.
Based on the idea behind emersion's change to drm_info
(https://github.com/ascent12/drm_info/commit/869e789a645b92a99e592a230fe39b0c59a2cd7d).
Lets us by default skip devices which are not capable of doing what
the DRM master output requires (not primary devices), as some devices
have card0 actually not be such.
Negative part is that the number given to drm-connector is no
longer a direct mapping against a file name.
Today, validation is only possible for string type options. But there's
no particular reason why it needs to be restricted in this way, and
there are potential uses, to allow other options to be validated
without forcing the option to have to reimplement parsing from
scratch.
The first part, simply making the validation function an explicit
field instead of overloading priv is simple enough. But if we only do
that, then the validation function still needs to deal with the raw
pre-parsed string. Instead, we want to allow the value to be parsed
before it is validated. That in turn leads to us having validator
functions that should be type aware. Unfortunately, that means we need
to keep the explicit macro like OPT_STRING_VALIDATE() as a way to
enforce the correct typing of the function. Otherwise, we'd have to
have the validator take a void * and hope the implementation can cast
it correctly.
For help, we don't have this problem, as help doesn't look at the
value.
Then, we turn validators that are really help generators into explicit
help functions and where a validator is help + validation, we split
them into two parts.
I have, however, left functions that need to query information for both
help and validation as single functions to avoid code duplication.
In this change, I have not added an other OPT_FOO_VALIDATE() macros as
they are not needed, but I will add some in a separate change to
illustrate the pattern.
On FreeBSD and DragonFly kernel checks if `frsig` is valid and aborts
with `EINVAL` if not. However, `frsig` was never implemented.
$ build/mpv --gpu-context=drm /path/to/video.mkv
[...]
[vo/gpu] VT_SETMODE failed: Invalid argument
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable.
[...]
$ ./waf configure
Checking for vt.h : no
Checking for DRM : vt.h not found
[...]
../test.c:1:10: fatal error: 'sys/vt.h' file not found
#include <sys/vt.h>
^~~~~~~~~~
$ build/mpv --gpu-context=drm /path/to/video.mkv
Error parsing option gpu-context (option parameter could not be parsed)
Setting commandline option --gpu-context=drm failed.
Exiting... (Fatal error)
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
Seems like some drivers only increment msc every other page flip when
running in interlaced mode (I'm looking at you nouveau). I.e. it seems
to be incremented at the frame rate, rather than the field rate.
Obviously we can't work with this, so shame the driver and bail.
On intel this isn't an issue, as msc is incremented at field rate
there.
This means presentation feedback won't work correctly in interlaced
modes with those drivers, but who in their right mind uses an
interlaced mode these days, anyway?
This allows to select the drm mode using a string specification. You
can either select the the preferred mode, the mode with the highest
resolution, by specifying WxH[@R] or by its index in the list of modes
as before.
Dudemanguy
nanahi
Kacper Michajłow
Brad Smith
sfan5
Guido Cella
NRK
llyyr
LaserEyess
Christoph Heinrich
Aaron Boxer
Philip Langdale
Noralf Trønnes
Jan Ekström
Jan Beich
wm4
Anton Kindestam