summaryrefslogtreecommitdiffstats
path: root/video/out/drm_common.c
Commit message (Collapse)AuthorAgeFilesLines
* various: use thread safe mp_strerror()nanahi10 days1-1/+1
|
* vo_drm: add support for YUYV formatsfan513 days1-1/+3
| | | | | | | | | | 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>
* various: avoid function pointer castsKacper Michajłow2024-02-281-2/+1
| | | | | | | | | | | | | 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.
* vo: don't sleep 1ms always when requested time is in the pastKacper Michajłow2023-11-091-1/+1
| | | | | | | | | | | | | | 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
* present_sync: remove unneeded clear_values functionDudemanguy2023-11-071-1/+0
| | | | | | | | | 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.
* present_sync: only save as many entries as the swapchain depthDudemanguy2023-11-071-1/+1
| | | | | | Saving more than the swapchain depth is just wasteful. We can just save a copy of the vo_opts here and check the value whenever we're updating values.
* vo: replace max swapchain depth magic numberDudemanguy2023-11-071-1/+1
|
* drm: use present_sync mechanism for presentation feedbackDudemanguy2023-11-061-64/+10
| | | | | | | | | | | 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.
* various: remove trailing whitespaceGuido Cella2023-10-301-1/+1
|
* timer: use MP_TIME macrosKacper Michajłow2023-10-261-1/+1
|
* drm_common: don't spoil errno in signal handlerNRK2023-10-131-0/+2
| | | | same rationale as last commit
* vo: use mp_poll wrapper in wait_events when applicableDudemanguy2023-10-101-4/+5
| | | | | | | | | | 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.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-101-4/+4
| | | | | | | | | | | | 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, 37d6604d70c8c594de2817db26356c4c950ac0fd 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.
* vo: change vsync base to nanosecondsKacper Michajłow2023-09-291-3/+3
| | | | | There is no reason to use microseconds precision. We have precise timers all all relevant platforms.
* drm: remove selecting the card number with --drm-connectorDudemanguy2023-09-211-18/+1
| | | | | | f56043759494dd584c8d82e7890f92fada18e34b deprecated this since the --drm-device path option was added as a replacement. Drop the card number selection logic.
* options: remove ancient option fallbacks/deprecationDudemanguy2023-09-211-4/+0
| | | | | | | | | | | | | 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. 26f4f18c0629998a9b91e94722d166866d8b80a3 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.
* drm_common: skip cards that don't have connected outputsllyyr2023-08-201-0/+29
| | | | | | 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.
* drm: bump minimum version to 2.4.105LaserEyess2023-07-311-4/+0
| | | | | Debian 12 is out, with 2.4.114, and Ubuntu 22.04 has 2.4.110, this #ifdef is no longer needed
* options: remove explicit initialization of integers to 0Christoph Heinrich2023-02-211-1/+0
|
* drm: rewrite based around vo_drm_stateDudemanguy2023-01-211-434/+647
| | | | | | | | | | | 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.
* drm: remove legacy APILaserEyess2022-11-161-7/+6
| | | | | | | | | | | | | 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.
* drm_common: remove hard dependency on drmIsKMS()sfan52022-08-111-5/+14
| | | | | | ae768a1e141eb88243e46757d41ca0cada9502b4 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.
* drm_common: skip cards that don't support KMS for autodetectionsfan52022-08-031-0/+15
| | | | | | 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.
* wayland: use mp_tag_str not drm_format_stringDudemanguy2022-05-301-448/+0
| | | | | | | | | | | 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
* vo: add new vaapi-wayland driverAaron Boxer2022-05-241-0/+449
| | | | | | | 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.
* drm: context_drm_egl: add support for enabling VRRPhilip Langdale2022-04-051-0/+3
| | | | | | | | | | | | | | 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.
* context_drm_egl: add support for BGR surface formatsPhilip Langdale2021-11-101-1/+3
| | | | | | | | | | | | 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.
* drm_common: add connector types USB, SPI and WritebackNoralf Trønnes2021-10-261-0/+3
| | | | Add support for the newly added USB connector type and also SPI and Writeback.
* drm_common: support unknown connector typesNoralf Trønnes2021-10-261-2/+9
| | | | | Avoid 'Segmentation fault' by using the connector type name UNKNOWN if the connector type is not known to mpv.
* drm_common: enable specific device selection by means of pathJan Ekström2021-10-251-2/+16
|
* drm_common: utilize drmGetDevices when iterating over cardsJan Ekström2021-10-251-28/+111
| | | | | | | | | | | | 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.
* options: Make validation and help possible for all option typesPhilip Langdale2021-03-281-25/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* drm_common: set frsig to a valid signalJan Beich2020-04-221-0/+3
| | | | | | | | | | | 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. [...]
* build: detect VT_GETMODE on FreeBSD and DragonFlyJan Beich2020-04-221-1/+8
| | | | | | | | | | | | | | | | $ ./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)
* options: change option macros and all option declarationswm42020-03-181-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* drm: avoid division by 0 in drm_pflip_cb with bad driversAnton Kindestam2019-12-071-0/+9
| | | | | | | | | | | | | | 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?
* drm_common: fix display FPS estimation for interlaced modessfan52019-12-071-1/+4
|
* drm_common: log more useful thingssfan52019-12-071-0/+18
|
* drm: refactor page_flipped callbackAnton Kindestam2019-09-281-0/+48
| | | | | Avoid duplicating the same callback function in both context_drm_egl and vo_drm.
* drm_common: add missing zero-initialization of struct vt_mode variableAnton Kindestam2019-09-241-1/+1
| | | | | Some fields were being left uninitialized. This could be a problem particularly on non-Linux OS:s with vt_mode (see PR #6976).
* drm_common: Support --drm-mode=<preferred|highest|N|WxH[@R]>Anton Kindestam2019-05-041-12/+226
| | | | | | | 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.
* drm_common: Don't export functions only being used internallyAnton Kindestam2019-05-041-9/+22
| | | | | As far as I know none of these functions were being used outside of drm_common, nor should there really be a need to use them.
* drm_common: Add proper help option to drm-modeAnton Kindestam2019-05-041-20/+82
| | | | | | | This was implemented by using OPT_STRING_VALIDATE for drm-mode, instead of OPT_INT. Using a string here also prepares for future additions to drm-mode that aim to allow specifying a mode by its resolution.
* drm_common: Add option to toggle use of atomic modesettingAnton Kindestam2019-05-041-4/+10
| | | | | | It is useful when debugging to be able to force atomic off, or as a workaround if atomic breaks for some user. Legacy modesetting is less likely to break by virtue of being a less complex API.
* drm: rename plane options to better, invariant, namesAnton Kindestam2018-12-011-7/+12
| | | | | | | | | | | | | | | | | | | | | This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
* drm_atomic: Add general primary/overlay plane optionAnton Kindestam2018-12-011-4/+9
| | | | | | | | | | Add general primary/overlay plane option to drm-osd-plane-id and drm-video-plane-id, so that the user can just request any usable primary or overlay plane for either of these two options. This should be somewhat more user-friendly (especially as neither of these two options currently have a useful help function), as usually you would only be interested in the type of the plane, and not exactly which plane gets picked.
* context_drm_egl: Fix CRTC setup and release code when using atomicAnton Kindestam2018-07-091-4/+4
| | | | | | | | | | The previous code did not save enough information about the old state, and could end up changing what plane the fbcon:s FB got attached to, or in worse case causing a blank screen (observed in some multi-screen setups on Sandy Bridge). In addition refactor the handling of drmModeModeInfo property blobs to not leak, as well as enable reuse of already created blobs.
* drm_common: Be smarter when deciding on which CRTC and Encoder to useAnton Kindestam2018-05-011-1/+27
| | | | | | | | | | | | | | | | | Inspired by kmscube, first try to pick the Encoder and CRTC already associated with the selected Connector, if any. Otherwise try to find the first matching encoder & CRTC like before. The previous behavior had problems when using atomic modesetting (crtc_setup_atomic) when we picked an Encoder & CRTC that was currently being used by the fbcon together with another Encoder. drmModeSetCrtc was able to "steal" the CRTC in this case, but using atomic modesetting we do not seem to get this behavior automatically. This should also improve behavior somewhat when run on a multi screen setup with regards to deinit and VT switching (still sometimes you end up with a blank screen where you previously had a cloned display of your fbcon)
* drm/atomic: refactor planes namesLongChair2018-05-011-3/+8
| | | | | | | | We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video. This commit is doing two things : - replace the primary / overlay planes members with osd and video planes member without the assumption - Add two more options to determine which one of the primary / overlay is associated to osd / video. - It will default osd to overlay and video to primary if unspecified
* drm/atomic: add connector to atomic contextLongChair2018-05-011-1/+2
| | | | | | | | | | This patch adds - DRM connector object to atomic context. - fd property to the drm atomic object as well as a method to read blob type properties. This allows to ensure that the proper connector is picked up, especially when specifying it from the commandline, and also allows to make sure we're using the right one when embedding with interop into an application.
* drm/atomic: refactor hwdec_drmprime_drm with native resourcesLongChair2018-05-011-0/+1
| | | | | | | | | | | | | | | | | That new API was introduced and allows to have several native resources. Thisuses that mechanisma for drm resources rather than the deprecated opengl-cb structs. This patch therefore add two structs that can be used with the drm atomic interop. - mpv_opengl_drm_params : which will hold all the drm handles - mpv_opengl_drm_osd_size : which will hold osd layer size This commit adds a drm-osd-size=WxH parameter to commandline which allows to define the OSD plane dimension. OSD can be upscaled to screen resolution when having OSD at video resolution is too heavy. This is especially useful for UHD modes on embedded devices where the GPU cannot handle UHD modes at a decent framerate.
* drm_common: Improve VT switching signal handling somewhatAnton Kindestam2018-02-261-1/+15
| | | | | | | | By blocking the VT switcher signal in the VO thread we get less races and other oddities. This gets rid of tearing (at least for me) when VT switching with --gpu-context=drm.
* context_drm_egl: Introduce 30bpp supportAnton Kindestam2018-02-261-0/+3
| | | | | | | | | | | | | This introduces the option --drm-format (currently used only by context_drm_egl, vo_drm implementation is pending) which allows you to pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm. Requires a recent mesa (18.0.0_rc4 or later) to work. This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled mesa (allow_rgb10_configs set to true). Previously it would've set up an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would be picked, resulting in a garbled image.
* video : Move drm options to substruct.Lionel CHAZALLON2017-10-231-0/+12
| | | | | This allows to group them and most of all query the group config when needed and when we don't have the access to vo.
*