summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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 maximized state. GET_UNFS_WINDOW_SIZE is meant to report the size except for when it is fullscreen (hence UNFS). However, the actual function was merely returning the wl->window_size so it was wrong for maximized windows. Workaround this by returning wl->geometry instead when we have the maximized case. Fixes #9207.
* win32: initial position: center with bordersAvi Halachmi (:avih)2021-09-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Previously, the initial positioning and fit ignored the borders, and centered the content (the video itself) at the working area. Now, the initial positioning centers the window, by subtracting the borders (if needed) from the target area for the initial fit/position. While this does mean that the initial maximum content area is now smaller than before, ultimately this has no impact on the window size, because fit_on_screen is called later and, if needed, further shrinks the window to fit the borders too - but without centering the window. So the net impact of this commit is only the initial positioning (same size as before), which now centers the window instead of the content. Note that on Windows 10 the borders include invisible areas at the sides and bottom of the window (for mouse edge-drag), so visibly the window is nearer to the top than to the bottom, but these are the metrics we have (fit_on_screen uses the same border size values). On Windows 7 it looks perfectly centered.
* win32: fix incorrect application of --monitoraspectAvi Halachmi (:avih)2021-09-061-1/+4
| | | | | | | | | | | | | The --monitoraspect value is calculated at vo_calc_window_geometry2 (VCWG2) or VCWG3, and applied via vo_apply_window_geometry. Before this commit, the screen size which the win32 VO used with VCWG2 was the working area (screen minus taskbar). This allows better fitting, but breaks the pixelaspect calculation which is derived from the --monitoraspect value and this rectangle. VCWG3 allows an independent size for the aspect calculations, and now we use it independently of the fit size.
* win_state: add vo_calc_window_geometry3Avi Halachmi (:avih)2021-09-062-5/+21
| | | | | | | | | | | | | | | | | vo_calc_window_geometry2 (VCWG2) calculates both the pixelaspect and the autofit sizes based on one "screen" rectangle. However, these two calculations might need two different "screen" rects if the fit should take into account decorations and/or taskbar etc, while pixelaspect should be based on the full (monitor) rect. VCWG3 does just that. It's the same as VCWG2, but with an additional monitor rect which is used exclussively to calculate pixelaspect, while the "screen" argument is used for fitting (like before). VCWG2 now uses/calls VCWG3 with the same screen and monitor rects. Currently yet unused.
* wayland: set default cursor size to 24Ivan2021-08-281-1/+1
| | | | | Set it to 24 if it couldn't be read frome $XCURSOR_SIZE for some reason. Since it seems to be the default value for most distros/DE.
* wayland: read XCURSOR_THEME to get cursor themeIvan2021-08-281-1/+2
| | | | | Read $XCURSOR_THEME environment variable if set and if not then fall back to "default" (/usr/share/icons/default and ~/.icons/default)
* vo_tct: add resize capabilityCloud116652021-08-261-0/+7
| | | | No performance penalty added by getting the terminal size every frame.
* vo_drm: fix typo in error messagea13460542021-08-261-1/+1
|
* win32: support the property display-hidpi-scaleAvi Halachmi (:avih)2021-08-181-0/+4
| | | | | | | | This read-only property reflects the VO's dpi-scale value, and wasn't supported on win32 until now (it is supported on wayland/x11/osx). Currently in mpv it's only used by the builtin script console.lua, and assumed 1 if unavailable.
* win32: apply dpi-scale with [current]-window-scaleAvi Halachmi (:avih)2021-08-181-2/+5
| | | | | | | | | | | | | | When --window-scale=NUM is set from CLI, the dpi_scale value was/is taken into account when the win32 VO calls vo_calc_window_geometry2. However, when [current]-window-scale is read or set at runtime, it uses the VOCTRL_{GET,SET}_UNFS_WINDOW_SIZE interface, where other VOs apply the dpi_scale value internally (wayland, x11, osx), but the win32 VO didn't before this commit. Fixes two issues when --hidpi-window-scale=yes and dpi_scale != 1 : - Incorrect window-size when setting [current-]window-scale at runtime. - Incorrect current-window-scale value when reading it.
* win32: ensure initial dpi-scale valueAvi Halachmi (:avih)2021-08-181-14/+19
| | | | | | | | | | | | | | | | | | | | vo_calc_window_geometry2(...) is called to initialize the window size with the dpi_scale value as one of the arguments. dpi_scale is 0 initially, and set to a valid value at update_dpi(), which is called from [force_]update_display_info(). However, no measures were taken to ensure that dpi_scale is set correctly before vo_calc_window_geometry2() is called, which could result in incorrect window size if it's not initialized. It did happen to get initialized on time, by luck, because VOCTRL_GET_DISPLAY_FPS is used early, which happens to call update_display_info to read the fps value (other update_display_info() calls are after the first vo_calc_window_geometry2() call). This commit ensures that dpi_scale is initialized on time if needed. Also, update_dpi() now ensures that dpi_scale is never 0.
* vo_tct: fix --vo-tct-256Avi Halachmi (:avih)2021-08-161-3/+3
| | | | | | | | | | | | | | | This is a regression from cbbd81bb (the previous commit): print_seq1 (which prints a sequence with 1 parametric byte value) is used with 256 colors output, and apparently was never tested. Two issues were introduced at the offending commit: 1. The ";5" part was incorrectly removed from the strings ESC_COLOR256_{BG,FG} (affects both *nix and Windows). 2. On windows only - a semicolon was not used after the prefix. Both issues resulted in an invalid 256 colors sequences and output.
* vo_tct: optimize print function on non-windows platformsCloud116652021-08-161-14/+57
| | | | Using fwrite on non-windows platforms yields a ~25% performance increase.
* vo_tct: fix half-block on windowsAvi Halachmi (:avih)2021-08-161-0/+1
| | | | | | | On windows the UTF-8 strings are translated to wchar_t when printed to the console, and some escape sequences are also translated, however, this only works when printf is mapped to mp_printf, and for that to happen we need to include osdep/io.h .
* wayland: check for xkb state in handle modifiersDudemanguy2021-08-151-3/+4
| | | | | | | | | | | | | | | | | | Normally in wayland, you receive a keymap event from the compositor which is what allows the client to setup what is needed for xkb. However, it turns out that this doesn't occur in the case of virtual keyboards, such as from wtype, that come from the custom virtual-keyboard protocol. What happens in this case is that mpv only receives a keyboard entrance event. According to the wayland protocol documentation [1], "the compositor must send wl_keyboard.modifiers event after [the wl_keyboard.enter] event". It is possible for this to occur before the physical keyboard is properly mapped (i.e: using a virtual keyboard to start mpv). What this results in is a segfault once xkb_state_update_mask is called in the modifiers event. The fix is to simply not always assume we have created the xkb state if we get this event and check for its existence first. Closes #9119. https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard
* vo_rpi: restore fullscreen handlingHo Ming Shun2021-08-131-0/+20
| | | | | | | Previous fullscreen handling code was removed in 59cdfe50b2 during deprecation of VOCTRL_FULLSCREEN. Lack of this code caused the OSD layer to be to be not resized along with the video layer when fullscreen is toggled.
* x11: handle maximized windows with window-scaleDudemanguy2021-08-121-0/+6
| | | | | | | If a user attempted to change the window scale of a maximized window on x11, nothing would happen since the window manager holds the size of the window constant. Just do an unmaximize first before performing the resize.
* vo_vdpau: Don't treat preemption as an error when reconfiguringsjambekar2021-08-121-1/+11
| | | | | | | | | | | | | | | | | | | When the VT switch out is triggered, the decode thread (VD) falls back to sw decoding. However, on the VO thread, which is responsible for handling display preemption and presentation, vo_vdpau.c:reconfig() is called. The reconfig() function returned -1 when the check_preemption() returned 0. The vo_reconfig2() (which calls reconfig()) returned -1 in turn which entered into an error handling path. This led to a series of functions calls that ultimately set the in_terminate flag to TRUE. This led the vo_thread to exit which ultimately led to the MPV application exit. The fix is to return 0 instead of -1 after the check_preemption() in the vo_vpdau.c:reconfig(). Returning 0 instead of -1 is not fatal and does not have any side effects. This is confirmed by testing the VT switching behaviour. And as far as the frames that are going to the display are concerned, they are now dropped. Since the display is preempted, it is okay to drop the frames and continue.
* wayland: fix wrong opts structDudemanguy2021-08-101-1/+1
|
* wayland: request xdg-decoration mode on startupDudemanguy2021-08-101-0/+2
| | | | | | Right after the listener is constructed, request a mode based on the value of the border option. If border, then request SSD. If no border, request CSD. The decoration listener handles it from there.
* vo_wlshm: remove empty options structDudemanguy2021-08-091-6/+0
| | | | | This doesn't do anything and isn't needed as there are no wlshm-specific options.
* wayland: check for xdg-decoration on border updateDudemanguy2021-08-091-1/+1
| | | | | Oversight in 69c64f5. If there is no xdg_toplevel_decoration, don't attempt to set the mode.
* wayland: handle xdg-decoration protocol betterDudemanguy2021-08-091-9/+22
| | | | | | | | | | | | | | | | | | | | | The current usage of the xdg-decoration protocol is quite a bit crude. There's a specific listener struct for this like with most wayland things, but mpv wasn't even using it. It also made no attempt to detect if the compositor was telling mpv to use client side decorations. To implement this correctly, first of all we need to create the decoration listener object and add it like how most wayland things work. Secondly, set_border_decorations needs to be changed to accept the uint32_t mode given by the compositor. When we get the decoration event, pass the mode obtained from the compositor to set_border_decorations. Update the mpv border option, based on whether or not we have server side decorations (yes if we have them; no if we don't). mpv can actually request either client side or server side decorations with this protocol. This function doesn't belong in set_border_decorations but rather it should be called when the border option changes. Whether or not this request actually works depends on the compositor (Plasma appears to allow it; sway does not). If the compositor allows this request, then it gets handled by configure_decorations. Note that the enum strangely starts at 1 hence why there is an extra +1.
* wayland: fix keepaspect-window during resizeDudemanguy2021-08-081-9/+6
| | | | | | | | | | | | So the resizing mechanism is actually supposed to match the video size to the window size while preserving the aspect ratio. In wayland, the current logic behaves as if --no-keepaspect-window was set. Fix this by simply multiplying the height by the same scale factor the width is multiplied by. Also get rid of the pointless (width > height) test (it makes no difference in any case) as well as some unneccesary checks for the keepaspect-window option. The use of ceil here is to make sure the window coordinates can never possibly have be 0 due to truncation (weston can still give you a 1x1 window which is fun). Fixes #9098.
*