summaryrefslogtreecommitdiffstats
path: root/video/out/drm_common.h
Commit message (Collapse)AuthorAgeFilesLines
* vo_drm: add support for YUYV formatsfan512 days1-4/+7
| | | | | | | | | | 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>
* drm: use present_sync mechanism for presentation feedbackDudemanguy2023-11-061-17/+1
| | | | | | | | | | | 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.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-101-1/+1
| | | | | | | | | | | | 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.
* drm: rewrite based around vo_drm_stateDudemanguy2023-01-211-47/+72
| | | | | | | | | | | 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-2/+1
| | | | | | | | | | | | | 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.
* wayland: use mp_tag_str not drm_format_stringDudemanguy2022-05-301-2/+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/+2
| | | | | | | 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/+1
| | | | | | | | | | | | | | 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-0/+2
| | | | | | | | | | | | 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: enable specific device selection by means of pathJan Ekström2021-10-251-1/+4
|
* drm_common: utilize drmGetDevices when iterating over cardsJan Ekström2021-10-251-0/+1
| | | | | | | | | | | | 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.
* drm: avoid division by 0 in drm_pflip_cb with bad driversAnton Kindestam2019-12-071-0/+1
| | | | | | | | | | | | | | 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: refactor page_flipped callbackAnton Kindestam2019-09-281-0/+11
| | | | | Avoid duplicating the same callback function in both context_drm_egl and vo_drm.
* drm: move struct vsync_tuple into drm_common as drm_vsync_tupleAnton Kindestam2019-09-281-0/+6
| | | | This struct will be useful in vo_drm as well.
* drm_common: Don't export functions only being used internallyAnton Kindestam2019-05-041-13/+0
| | | | | 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-2/+8
| | | | | | | 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-1/+3
| | | | | | 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-4/+4
| | | | | | | | | | | | | | | | | | | | | 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.
* context_drm_egl: Fix CRTC setup and release code when using atomicAnton Kindestam2018-07-091-1/+1
| | | | | | | | | | 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/atomic: refactor planes namesLongChair2018-05-011-2/+3
| | | | | | | | 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: 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.
* context_drm_egl: Introduce 30bpp supportAnton Kindestam2018-02-261-0/+4
| | | | | | | | | | | | | 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/+6
| | | | | 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.
* Add DRM_PRIME Format Handling and Display for RockChip MPP decodersLionel CHAZALLON2017-10-231-1/+3
| | | | | | | | | | | This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor struct. That struct holds dmabuf fds and information allowing zerocopy rendering using KMS / DRM Atomic. This has been tested on RockChip ROCK64 device.
* vo_drm: change CLI options + refactorsrr-2016-10-071-4/+16
| | | | | | | | | | - Change connector selection to accept human readable names (such as eDP-1, HDMI-A-2) rather than arbitrary numbers. - Change GPU selection to accept GPU number rather than device paths. - Merge connector and GPU selection into one --drm-connector. - Add support for --drm-connector=help. - Add support for --drm-* in EGL backend. - Refactor KMS; reduce state sharing across drm_common.
* vo_drm: refactor getting display fpsrr-2016-10-041-0/+1
| | | | | | | | Reduces code duplication between OpenGL backend and DRM VO. (The control() for OpenGL backend isn't sufficiently similar to the VO's control() to consider merging it as a whole - I extracted only the FPS code.)
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* vo_drm: use bool rather than integer return valuesrr-2015-11-081-2/+3
| | | | | Since the errors weren't used for anything other than simple success/fail checks, I simplified things a bit.
* vo_drm: move initialization to drm_commonrr-2015-11-081-0/+16
| | | | | Makes KMS initialization procedures reusable so that they can be used by the upcoming DRM EGL adapter.
* vo_drm: extract vt_switcher to drm_commonMarcin Kurczewski2015-04-191-0/+36