summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* context_drm_egl: make use of mpegl_create_window_surface()sfan52021-11-171-11/+3
| | | | This does what 3a10210c568f9c7d969ca6c4da2377c55fbf30f3 was supposed to, but better.
* egl_helpers: introduce wrapper around eglCreatePlatformWindowSurfacesfan52021-11-172-12/+50
| | | | | | It abstracts EGL 1.5, extension checks and other inconsistencies away. This can be used in context code as the (preferred) alternative to eglCreateWindowSurface().
* video: opengl: use gl_check_extension() instead of strstr()sfan52021-11-176-9/+8
| | | | | | Using a simple substring match for extension checks is considered bad practice because it's incorrect when one extension is a prefix of another's name. This will almost surely not make a difference in practice but do it for correctness anyway.
* context_drm_egl: use mpegl_get_display() helper over own codesfan52021-11-171-12/+7
| | | | | | Although there are no known problems with this, using the helper should be more portable. It will also prefer EGL 1.5's eglGetPlatformDisplay over eglGetPlatformDisplayEXT if available.
* vo_gpu: vulkan: open DRM render fd when using VK_KHR_displayPhilip Langdale2021-11-151-2/+102
| | | | | | | | | | | | | | | While the basic Vulkan Display context can theoretically drive the display without the involvement of any non-Vulkan code, that prevents us from using VAAPI acceleration. When initialising VAAPI without a window system, we need to provide it with an opened DRM render fd corresponding to the device to use. In the context of using VK_KHR_display, that means we need to identify which DRM device matches the selected Vulkan device, and then open its render fd and set the necessary state that VAAPI expects to find. With that done, the normal VAAPI<->Vulkan interop can kick in and we get working acceleration
* options: remove always true m_obj_list::allow_unknown_entriesEmil Velikov2021-11-151-1/+0
| | | | | | | Ever instance of m_obj_list is a constant and for all of them, the field is true. Just remove the field all together. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* egl_helpers: remove EGL_OPENGL_ES3_BITDudemanguy2021-11-111-2/+1
| | | | | | | | | | | | | | d2e8bc449986e012f257249a996386bd323febd0 was the the commit that originally introduced the usage of this bit. As the message states, the purpose was to force creating GLES 3 contexts on drivers that do not return a higher version context than what was requested. With the recent opengl refactors, mpv's gl selection has already moved away from such complicated queries. Perhaps when that commit was added things were different, but nowadays it seems like Mesa simply returns the highest driver version available that is compatibile with the request (i.e. requesting GLES 2 returns a GLES 3 context on my machine). In that case, let's just simply drop EGL_OPENGL_ES3_BIT altogether as it does break GLES 2 only machines. Fixes #9431.
* context_drm_egl: use eglCreatePlatformWindowSurfaceEXT if availablesfan52021-11-111-2/+12
| | | | | This is identical to eglCreateWindowSurface but should be preferred as part of EGL's platform extension.
* context_drm_egl: add support for BGR surface formatsPhilip Langdale2021-11-103-3/+34
| | | | | | | | | | | | 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.
* context_drm_egl: use gbm_surface_create_with_modifiersPhilip Langdale2021-11-101-9/+93
| | | | | | | | | The GBM supporting nvidia driver doesn't support creating surfaces without modifiers and using modifiers is more and more recommended as the right way to do this. Enumerating modifiers is painfully verbose, but necessary if we are to allow the driver to pick the best possible one.
* vo_gpu_next: fix slight performance regressionNiklas Haas2021-11-101-3/+1
| | | | | | | | This logic, which was working around a libplacebo bug, ended up always alpha blending - even for sources without an alpha channel. This caused a minor slowdown to be constantly enabled. Due to the recent bump to libplacebo v170, this is no longer needed.
* vo_gpu_next: Initialize `pl_frame_mix`Starsam802021-11-091-1/+1
| | | | | Without initializing, the random data causes the `pl_render_image_mix` function to abort with a SIGSEGV.
* vo_gpu_next: implement HDR passthroughNiklas Haas2021-11-081-0/+60
| | | | | | | | Completely untested, since Linux still can't into HDR in 2021. Somebody please make sure it works. Technically covers #8219, since gpu-context=drm can be combined with vo=gpu-next.
* vo_gpu_next: drop PL_API_VER checksNiklas Haas2021-11-081-8/+0
| | | | These are no longer needed with the minimum version bump.
* vo_gpu_next: fix resource exhaustion on minimized windowsNiklas Haas2021-11-081-2/+8
| | | | | | | | This required an upstream API change to implement in a way that doesn't unnecessarily re-push or upload frames that won't be used. I consider this a big enough bug to justify bumping the minimum version for it. Closes #9401
* wayland: remove bogus scale_change variableDudemanguy2021-11-082-24/+1
| | | | | | | | | This was originally added in f2afae55e95b4b1eec1aeb828ba6ff1f0695d993 for unclear reasons (way to go me). This concept is clearly incorrect. It doesn't matter what state the window is in. As soon as mpv detects a scale change, it needs to reset the buffer scale of the window. Just remove all this junk and put wl_surface_set_buffer_scale in set_surface_scaling like it should be. Related issue: #9426.
* vo_gpu_next: add automatic translation for ewa_lanczossharpNiklas Haas2021-11-071-0/+7
| | | | | | | This one hits a lot of people. Probably because the man page explicitly recommends it. Fixes #9408
* vo_gpu_next: implement --dither-depthNiklas Haas2021-11-071-0/+8
| | | | | | I somehow completely forgot about this option existing. Closes #9416
* vo_gpu_next: remove --builtin-scalers optionNiklas Haas2021-11-071-4/+0
| | | | | | | | | | | Looking at this again I'm not sure it does anything useful at all. The man page entry is also wrong: `bicubic` is not affected, only `bicubic_fast`, and those filters are not configurable anyways. So this would only ever be a debugging option, and I don't see a pressing need for it. No interface-change.rst update because it only just got added anyways.
* vo_gpu_next: call start_frame in vulkan/context.cDudemanguy2021-11-042-2/+12
| | | | | | | | | In practice, this is for wayland. vo_gpu_next doesn't check the check_visible parameter since it didn't descend into the vulkan/context.c file when starting a frame. To make this happen, just call the start_frame function pointer but pass NULL as the ra_fbo. In there, we can do the visibility checks and after that bail out of the start_frame function if ra_fbo is NULL.
* wayland_vk: rename start_frame to check_visibleDudemanguy2021-11-043-9/+10
| | | | | | | | | | This vulkan-specific parameter was poorly named and probably causes confusion. Just rename it to check_visible instead to make clear what is going on here. Only wayland uses it for now but in theory anyone else can. As an aside, wayland egl accomplishes this by using an external swapchain instead (an opengl-only concept in the mpv code). This may or may not need to be changed in the future when gpu-next gets opengl support.
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-034-10/+10
| | | | | It was pointed out on IRC that the name is misleading, since the actual semantics of the macro is to assert first.
* vo_gpu_next: fix --tone-mapping-param mappingNiklas Haas2021-11-031-0/+2
| | | | | | vo_gpu defaults this to NAN, libplacebo uses 0.0 as the default. Fixes https://github.com/mpv-player/mpv/issues/9386
* vo_gpu_next: add new libplacebo-based rendererNiklas Haas2021-11-034-0/+1396
| | | | | | | | | | | | | As discussed in #8799, this will eventually replace vo_gpu. However, it is not yet complete. Currently missing: - OpenGL contexts - hardware decoding - blend-subtitles=video - VOCTRL_SCREENSHOT However, it's usable enough to cover most use cases, and as such is enough to start getting in some crucial testing.
* osdep: add MP_UNREACHABLENiklas Haas2021-11-033-3/+3
| | | | | | | | | 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.
* vo_gpu: allow using bare windows as --(t)scaleNiklas Haas2021-11-031-0/+20
| | | | | | | | | | | A lot of people seem to do something like --tscale=box --tscale-window=<function>. Just let them use --tscale=<function> directly, by also accepting raw windows. Kinda hacky but needed for feature parity with vo_gpu_next, which no longer has `--tscale=box`. Note that because the option struct is still shared, vo_gpu_next inherits the same option handling code, so we have to export this feature for vo_gpu as well.
* vo_gpu: vulkan: expose swapchain to mpvk_ctxNiklas Haas2021-11-032-8/+8
| | | | So I can reuse it in vo_gpu_next.
* vo_gpu: lift ra_ctx_* opts to a global structNiklas Haas2021-11-037-68/+60
| | | | So I can re-use them for vo_gpu_next.
* player: fix autofit/geometry related segfaultDudemanguy2021-11-032-5/+11
| | | | | | | | | | | | | | | | | | | | | | | Back when runtime updating of autofit/geometry was added for wayland and x11 (commits: 4445ac828dca0298543103094357e64f8828ef56 and ced92ba607ebd98687b26ef3d8c09d5f6e22cf4b respectively), the naive assumption was that window-related geometry would always be available. While this is true 99% of the time, this isn't a guarentee. It is possible for certain things such as loading shaders to delay starting up the player. This causes autofit/geometry options to be registered as a runtime update and triggers VOCTRL_VO_OPTS_CHANGED. This ends up calling some geometry-related functions but this happens before the actual values are available. Hence, a nullptr was accessed which segfaults. At least one user experienced this with a combination of options in wayland but in theory the same thing could happen under x11. The fix is simple. Just be sure to check that the required geometry is available before doing any calculations. In wayland, this would be wl->current_output. Additionally add an assert to set_geometry (we should never use this function without wl->current_output) to be extra sure. In x11, the check is on x11->window. Later when the reconfig for each backend actually happens, the autofit/geometry set by the user happens anyway so ignoring it in this case does no harm. Fixes #9381.
* vo_gpu: libplacebo: simplify tex transfers for libplacebo 168+Niklas Haas2021-10-311-9/+19
| | | | | | | | | | | | Upstream libplacebo got refactored to use byte-sized strides rather than texel-sized strides. This commit makes mpv's ra_pl wrapper take advantage of that, rather than forcing a stride-fixing memcpy. Note that, technically, we would still need a stride fixing memcpy in cases when the true stride is not a multiple of the format's texel *alignment*, however this is a much rarer case and extremely unlikely to occur in practice, since all relevant formats use power-of-two texel alignments.
* wayland: remove incorrect keepaspect checkDudemanguy2021-10-261-2/+1
| | | | | | | | | | | In the reconfig event, the keepaspect option was checked before setting the window_size geometry to the new params obtained from the vo. This is incorrect. If a user disabled keepaspect on wayland, the video's size would not change on a reconfigure event (i.e. loading a new video in the playlist with a different size). No other windowing backend (x11, win32, etc.) behaves like this or uses keepaspect in its code like wayland did in this case. Clearly, this is not correct. Such functionality should be handled by a separate option entirely. Just remove this if statement.
* 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-254-4/+24
|
* drm_common: utilize drmGetDevices when iterating over cardsJan Ekström2021-10-252-28/+112
| | | | | | | | | | | | 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.
* vo_gpu: fix rotated compute shader vertex simulationNiklas Haas2021-10-221-10/+2
| | | | | | | | Upon re-examination I have no idea why this code was ever written or what problem it was trying to solve. But, getting rid of it fixes #9291. It might be a remnant from before 2af2fa7a27. Who knows. This code will be replaced soon(tm) anyways.
* egl_helpers: ensure debug context attrs/bit existDudemanguy2021-10-211-0/+9
| | | | | | | Regression from e13fe1299d8aefdc264e74159cce07b8bfcf722c. Apparently, Broadcom's EGL does not support the EGL_CONTEXT_FLAGS_KHR attribute nor EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR. Just define these as EGL_NONE and 0 respectively if we do not have them.
* egl_helpers: add support for debug contextsEmil Velikov2021-10-161-0/+4
| | | | | | | With the recent refactor and quick look against the GLX code path, it's fairly obvious, and trivial, how to add support for debug contexts. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: context_glx: cleanup create_context_x11_gl3 code pathEmil Velikov2021-10-161-23/+37
| | | | | | | | | | | | | | | | | | | Drop the gl3 suffix from the function name - it's no longer needed, with the _old function gone. Push the mpgl_min_required_gl_versions[] looping within the function, reducing the identical glXGetProcAddress/glXQueryExtensionsString calls while making the code neater. v2: - tabs -> spaces indentation - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions - 320 -> 300 (in glx code path) v3: - legacy code path is gone \o/ Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: context_glx: remove legacy create_context_x11_old()Emil Velikov2021-10-161-43/+9
| | | | | | | | | | | | | | | | | | | | | | | | | The old/legacy code-path isn't really needed for mpv use-cases. In particular: All Mesa drivers (even GL 2.1 ones like lima/vc4) work fine with the "non-legacy" path. From proprietary/binary drivers - the vendor either does not support desktop GL or the drivers/HW is not actively supported. Looking at the Nvidia HW - anything GeForce 7 and older is GL 2.1 and lacks decent video acceleration. The latest official drivers are from 2017. All newer Nvidia HW is GL 3.3+ thus must have GLX_ARB_create_context as in the non-legacy path, while also good acceleration albeit via VDPAU in some cases. With the old path gone, provide meaningful error message in the very unlikely case that GLX_ARB_create_context is missing. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* egl_helpers: fixup the EGL_KHR_create_context-less codepathEmil Velikov2021-10-163-44/+9
| | | | | | | | | | | | | | | | | | | With earlier commit f8e62d3d82 ("egl_helpers: fix create_context fallback behavior") we added a fallback for creating OpenGL context while EGL_KHR_create_context is missing. While it looked correct at first, it is missing the eglMakeCurrent() call after creating the EGL context. Thus calling glGetString() fails. Instead of doing that we can just remove some code - simply pass the CLIENT_VERSION 2, as attributes which is honoured by EGL regardless of the client API. This allows us to remove the special case and drop some code. v2: - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* video: opengl: rework and remove ra_gl_ctx_test_version()Emil Velikov2021-10-164-46/+37
| | | | | | | | | | | | | | | | The ra_gl_ctx_test_version() helper is quite clunky, in that it pushes a simple check too deep into the call chain. As such it makes it hard to reason, let alone have the GLX and EGL code paths symmetrical. Introduce a simple helper ra_gl_ctx_get_glesmode() which returns the current glesmode, so the platforms can clearly reason about should and should not be executed. v2: - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions - 320 -> 300 (in glx code path) Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: opengl: remove --opengl-restrictEmil Velikov2021-10-161-8/+1
| | | | | | | | | | | | | | | | | | | | As the documentation of the toggle says - the implementation can (and will actually if they follow the GLX/EGL spec) return context version greater than the one requested. This happens with all Mesa drivers that I've tested as well as the Nvidia binary drivers. This toggle seems like a workaround for buggy drivers, yet it's lacking context about the vendor and version. Remove it for now - I'll be happy to reinstate it (partially or in full) as we get concrete details. This allows us to simplify ra_gl_ctx_test_version() making the whole context creation business easier to follow by mere mortals. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* egl_helpers: remove explicit GLES 3 requestEmil Velikov2021-10-161-23/+12
| | | | | | | | | | | | | | | | | | Alike the GL commit earlier - the EGL spec essentially mandates that implementation will return GLES 3.0+ (if supported by the driver), even though only GLES 2 is requested. The only thing we should watch out is - we should add both ES2_BIT and ES3_BIT as EGL_RENDERABLE_TYPE. This has been verified against the Mesa drivers (i965, iris, swrast) and Nvidia binary drivers. v2: - int es_version -> bool es - unloop create_context() execution Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: opengl: reduce versions in mpgl_preferred_gl_versionsEmil Velikov2021-10-164-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently mpv requires a bare minimum of GL 2.1, although it tries to use 3.2+ core contexts when possible. The GLX and EGL spec effectively guarantee that the implementation will give you the highest compatible version possible. In other words: Requesting 3.2 core profile will always give you core profile and the version will be in the 3.2 .. 4.6 range - as supported by the drivers. Similarly for 2.1 - implementation will give you either: - 2.1 .. 3.1, or - 3.2 .. 4.6 compat profile This has been verified against the Mesa drivers (i965, iris, swrast) and Nvidia binary drivers. As such, drop the list to 320, 210 and terminating 0. v2: - mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions - update ^^ comment Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* drm: re-enable drmSet/DropMaster callsEmil Velikov2021-10-151-14/+7
| | | | | | | | | | | | | | | The ioctls were disabled a while back since they error out and allegedly cause problem with X running in another VT. Omitting the ioctls is not cool, even as a workaround. If they fail, the user is supposed to fallback appropriately - use a suid wrapper, logind-like daemon or otherwise. As of kernel 5.10, they should just work in nearly all cases, so let's just reinstate the calls. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* context_drm_egl: re-enable drmSet/DropMaster callsEmil Velikov2021-10-151-17/+10
| | | | | | | | | | | | | | | The ioctls were disabled a while back since they error out and allegedly cause problem with X running in another VT. Omitting the ioctls is not cool, even as a workaround. If they fail, the user is supposed to fallback appropriately - use a suid wrapper, logind-like daemon or otherwise. As of kernel 5.10, they should just work in nearly all cases, so let's just reinstate the calls. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* vo_gpu: libplacebo: add missing includeNiklas Haas2021-10-041-0/+1
| | | | | This was removed from common.h upstream since it was a cyclic dependency. We need to re-import it into utils.h manually.
* vo_gpu: libplacebo: drop conditional code paths for old versionsNiklas Haas2021-10-043-34/+1
| | | | No longer needed with the bump to v3.104.
* vo_gpu: libplacebo: drop code deprecated in libplacebo v3Niklas Haas2021-10-043-13/+2
| | | | | This is only needed for back-compat with libplacebo v2, and will break due to upstream removal starting with libplacebo v4.
* wayland: further xdg-decoration/border refinementsDudemanguy2021-09-282-26/+40
| | | | | | | | | | | | The value of the border option should always match what the actual state of the window is. Previously if a compositor rejected the request by mpv, it did not correct itself. Also add some code to keep track of decoration requests. Anytime the state is changed, make the last saved request again (doesn't hurt and seems like intuitive behavior). Unfortunately, this isn't foolproof since options only send callback if the value is changed. (ex. on sway if the floating window has no border, and then is titled, setting the border value to "yes" does nothing since tiling the window already set the border value to "yes").
* vo_rpi: fix DISPMANX_UPDATE_HANDLE_T leakHo Ming Shun2021-09-281-3/+4
| | | | | | | | | | | | | | | Fixes handle leak that happened whenever tvservice callback was invoked. Powering on the TV causes HDMI unplug and attached events to be sent to the tvservice callback. This meant you could only power on/off your TV a finite number of times before you were unable to allocate additional resources from VideoCore (usually resulting in a "Could not get DISPMANX objects." error). Furthermore because the VideoCore kernel driver does not cleanup handles when a process dies, the only way to recover from the leak was to reboot the RPI.
* wayland: report correct window size when maximizedDudemanguy2021-09-131-2/+7
| | | | | | | | | In wayland_common, wl->window_size keeps track of the window's size when it is not in the fullscreen or maxi