summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu_next: invalidate cache object if requested by libplaceboHEADmasterKacper Michajłow5 hours1-3/+5
| | | | See: https://code.videolan.org/videolan/libplacebo/-/merge_requests/659
* terminal: add terminal_set_mouse_input functionnanahi7 hours3-6/+6
| | | | This function is used to enable/disable mouse input for win32 and unix.
* vo_{tct,sixel,kitty}: implement mouse supportnanahi7 hours3-0/+6
|
* w32_common: implement --show-in-taskbar optionnanahi7 hours1-1/+12
| | | | | When the window style changes, use WS_EX_TOOLWINDOW style to exclude the window from the taskbar and Alt+Tab switching.
* x11_common: implement --show-in-taskbar optionnanahi7 hours1-0/+18
| | | | | | | | | This adds a new option --show-in-taskbar, which controls whether mpv appears in taskbars. This is useful for picture-in-picture setups where the video window should not appear in taskbars. On X11, this can be controled by setting the _NET_WM_STATE_SKIP_TASKBAR window state.
* x11_common: detect wm support for _NET_WM_STATE_SKIP_TASKBARnanahi7 hours1-0/+2
|
* wayland: fix segfault in surface_handle_enter due to memory readllyyr3 days1-1/+2
| | | | Fixes: 895f40e150d4 ("wayland: only perform a rescale if window is on one output")
* wayland: check if scale actually changes in scaling eventsDudemanguy4 days1-2/+6
| | | | | | | The protocol strongly implies that this only happens when the value changes, and it's also what you would naturally expect. But maybe it's worth guarding this in cause for some reason the same value twice in a row happens.
* wayland: only perform a rescale if window is on one outputDudemanguy4 days2-34/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | The mpv window overlapping multiple outputs with different scale values can result in some weird behavior when dragging it from one monitor to another one. This is due to the way some compositors implement preferred_scale or preferred_buffer_scale (integer scale equivalent). Depending on the scale values, mpv window has to be resized to match the new scaling value (due to fractional scaling requiring a viewport). This can cause the window to become smaller and no longer overlap the monitor you were just trying to drag it to. Repeat this and the window will become smaller and smaller. Depending on the layout, the reverse can also happen (the window becomes larger). This can cause additional events to fire as the preferred_scale value may change again which does more weird things. It seems kwin is not affected by this because their implementation of preferred_scale sends the event only if the window is fully on the new monitor. Honestly, this is probably more logical anyway but we should at least deal with the other implementations better. Try to deal with it by reworking scaling changes so they only occur when the mpv window is fully on one monitor. If we get a preferred_scale event and there is an overlap, save it as a pending change to be performed on the next surface_enter or surface_leave event (whichever results in there being only one monitor. Some weird rendering glitches can still happen during overlap but this makes it usable again.
* vo_gpu_next: rotate target cropKacper Michajłow4 days1-2/+2
| | | | | | | | Turns out libplacebo uses unrotated target crop in relation to source. Use dst rect from VO, instead of extracting it from pl_frame, to avoid another unrotating operation. Fixes: a9354b36ca
* wayland: apply keepaspect options to wayland configure boundsDudemanguy5 days1-6/+15
| | | | | | | | Previously if mpv's size was constrained by the compositor's configure bounds event, there was no attempt to preserve the aspect ratio of the given coordinates if --keepaspect (the default) was used. Be sure to apply keepaspect to the bounded widths and heights if we are using this event.
* wayland: avoid unneeded calls to xdg_toplevel state functionsDudemanguy5 days1-11/+12
| | | | | | | | | | | The reconfigure event handles setting fullscreen, maximize, etc. We were implictly relying on the compositor to just ignore mpv if we set a redundant state (e.g. setting fullscreen when we're already fullscreen), but kwin actually doesn't and operates again. This causes some subtle issues when handling geometry on state changes. Rework the state change calls so they are only executed if wl->geometry_configured isn't set yet (i.e. the window just opened up for the first time). It's the only time this is actually needed.
* wayland: enforce a state change after a reconfigureDudemanguy5 days2-0/+12
| | | | | | | | If mpv is coming out of some locked size state (fullscreen, maximized, tiled), the window size given by the reconfigure event should be used assuming the --auto-window-size option is set. Fixes 8a9749b8a563f258342450160c98e9c02ebedc96
* vo_gpu_next: set target resolution to crop valueKacper Michajłow5 days1-2/+2
| | | | | Use rect of the actual image instead of FBO size which includes margins.
* mac/vulkan: add support for frame timing via presentation feedbackder richter8 days2-2/+25
|
* mac/window: fix window pinch gesture and modify current-window-scaleder richter8 days1-1/+1
| | | | | | | | | this will prevent jumping of the window size in the case the window size was 'externally' modified and not via the window-scale property, when using the pinch gesture. Fixes #11594 Fixes #13799
* vo_gpu_next: keep target params in priv instead of alocating itKacper Michajłow8 days1-4/+7
|
* Revert "vo_dmabuf_wayland: assume counter-clockwise rotations"Dudemanguy9 days1-4/+1
| | | | | | | | | | | | | This commit was originally sparked by a change in sway. When looking at the wording of the spec, it was believed that the rotation should be counter-clockwise. But that was interpreted incorrectly. The rotation direction in the spec is meant for compositors not clients. Clients should be rotating clockwise and compositors rotate it the opposite direction. Also see the discussion in upstream wayland*. *: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/369 This reverts commit 27ef1725e7724f4b6899e3992ac3a884db9fbe13.
* bstr: change bstr0_s to bstr0_lit, restrict it only for string literalsKacper Michajłow10 days1-10/+10
| | | | | | | | | Allows to avoid non-portable strlen usage. Also avoid "initializer element is not constant" warnings on older GCC that doesn't like explicit type specification in aggregate initialization. Co-authored-by: NRK <nrk@disroot.org> Co-authored-by: nanahi <130121847+na-na-hi@users.noreply.github.com>
* vo_tct: reduce lut_item size and generate it without snprintfKacper Michajłow10 days1-6/+11
|
* vo_tct: use fwrite when appropriateKacper Michajłow10 days1-11/+9
|
* vo_tct: add synchronized output supportKacper Michajłow10 days1-0/+4
| | | | See-Also: https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036
* vo_tct: add --vo-tct-buffering optionKacper Michajłow10 days1-9/+36
|
* misc/bstr: add bstr0_s for static initializationKacper Michajłow10 days1-12/+12
|
* vo_tct: write frame fully instead of every pixelKacper Michajłow10 days1-48/+44
| | | | | | | This is multiple times faster than just writing every pixel sequence separately. Especially on slower terminal emulators. In general no need to stress I/O, while we can just prepare the frame to print and do it once.
* vulkan: use pl_vk_inst_createKacper Michajłow10 days2-39/+39
| | | | | | | | | | | | This change is mostly motivated by missing VK_KHR_portability_enumeration instance extension when enumerating the devices. Which causes issues with MoltenVK which does not advertise full Vulkan conformance. To avoid duplicating code use pl_vk_inst_create() which correctly query availability and enables the mentioned extension. While at it fix the VkInstance leaking in vk_validate_dev().
* vo: add win32 context menu supportShuanglei Tao12 days4-0/+291
|
* mac/common: reuse hidpi window scale frame calculation helperder richter13 days1-4/+2
|
* mac/window: cleanup unfsContentFrame usage and make it none optionalder richter13 days1-10/+8
|
* mac/window: fix unfs window size retrievalder richter13 days2-0/+4
| | | | | | the unfsContentFrame wasn't updated when externally resized leading to a wrong unfs window size afterwards. update it on windowDidResize event when not in fs, not animating and not live resizing.
* wayland_common: set mouse position on pointer enternanahi2024-04-011-0/+7
| | | | | | | | | At least on some compositors, when the pointer enters a surface, only a wl_pointer_enter event is generated, but not wl_pointer_motion. This results in the initial mouse position being lost, which is especially problematic when input simulation is used. Fix this by setting the mouse position on pointer enter event.
* mac/view: fix cursor visibility when toggling fullscreender richter2024-03-291-3/+3
| | | | | | | | | | | this broke with the recent refactor of the input handling. one of the edge cases was not considered, where not every mouse down event has a corresponding mouse up event, eg all double clicks or more only have one up event after the first down event. this was handled correctly previously. Fixes #13777
* mac: cleanup swift bridge header imports and unify themder richter2024-03-293-2/+5
|
* mac/log: rename log functions and cleanup classder richter2024-03-295-29/+29
|
* mac: use LogHelper directly instead of mp_logder richter2024-03-293-8/+8
|
* mac: rename mpvHandle to mpvder richter2024-03-291-5/+4
|
* mac: remove now unnecessary objective-c forwardingder richter2024-03-291-1/+1
|
* mac/apphub: move menu bar into AppHubder richter2024-03-291-7/+5
|
* mac/apphub: move app icon into AppHubder richter2024-03-291-4/+2
| | | | | split up AppHub header in obj-c and c parts and make it a bidirectional bridging.
* win32: fix native key repeat supportnanahi2024-03-291-5/+2
| | | | | | | win32 does not respect --native-keyrepeat option, and native key repeat has been broken since 0ab3482f73a199b2e839ad4ec0a4b21adc1e75d5. This lets mpv respect the --native-keyrepeat option on win32.
* vo_gpu: support video-target-paramsnanahi2024-03-273-0/+27
|
* vo_direct3d: support video-target-paramsnanahi2024-03-271-0/+13
| | | | The backbuffer format is available.
* vo_xv: support video-target-paramsnanahi2024-03-271-0/+8
| | | | | The target colorspace depends on whether the xv adaptor supports setting BT.709 colorspace.
* cocoa-cb: use EventHelper for event handlingder richter2024-03-241-8/+4
|
* cocoa-cb: use a separate mpv_handle for cocoa-cb to simplify shutdownder richter2024-03-241-5/+4
|
* mac/apphub: migrate remaining events functionality to new AppHubder richter2024-03-241-1/+1
| | | | | | | | add new app_bridge objc file for bridging between mpv core and app functionality. replace old EventsResponder singleton with AppHub. another step to clean up all App functionality and have one central place for it.
* hwdec/vulkan: enable the stable AV1 extensionLynne2024-03-241-2/+1
| | | | | | | As no drivers were ever released with the unstable extension, it's not needed anymore. Not bumping the required headers version yet.
* mac: optimise and shorten some codeder richter2024-03-213-15/+6
|
* mac/option: remove now unused computed option variablesder richter2024-03-211-1/+0
|
* mac/option: rename option structs to properly represent their contentder richter2024-03-216-59/+59
| | | | also optimise option cache setup.
* mac/libmpv: remove mac option handling in favour of option handlerder richter2024-03-211-4/+4
| | | | | | since the option handler is not optional anymore and available on init in cocoa-cb we don't need to duplicate this functionality in libmpv anymore.
* mac/option: make option helper none optionalder richter2024-03-216-79/+49
| | | | gets rid of some unwrapping boilerplate and nil coalescing operators.
* mac/option: make option helper vo struct independentder richter2024-03-213-6/+9
|
* mac/option: remove unused and obsolete variablesder richter2024-03-212-2/+2
|
* mac/option: move option functionality from mpv helper to option helperder richter2024-03-216-90/+90
| | | | delete now empty mpv helper
* mac/type: move c<>swift type bridging into a dedicated type helperder richter2024-03-211-20/+20
|
* video/egl_helpers: fix fallback logic for EGL_KHR_create_contextsfan52024-03-211-3/+4
| | | | | | | | | | | | Both possible paths had bugs: For OpenGL it passed EGL_CONTEXT_CLIENT_VERSION, which - in older versions of the standard - was not permitted. For GLES it always assumed EGL_CONTEXT_FLAGS_KHR to work, which belongs to the aforementioned extension. Ironically this was never a problem (probably saved by implementations not being overly strict) except in 2024 on an emulated Android 14 device that trips over this edge case. It is a mystery.
* video/egl_helpers: log error for eglCreateContextsfan52024-03-211-1/+2
|
* various: use thread safe mp_strerror()nanahi2024-03-192-2/+3
|
* image_writer: fix TOCTOU in screenshot filename generationnanahi2024-03-191-1/+1
| | | | | | | | | | | | | | | | The screenshot command is documented to not overwrite existing files. However, there is a race window between the filename is generated with gen_fname and when the file is open to write. Specifically, the convert_image function in this window can be very time consuming depending on video and screenshot image format and size. This results in existing file being overwritten because the file writing functions don't check for the existance of file. Fix this be opening the file in exclusive mode. Add overwrite parameter to write_image for other operations that are documented to overwrite existing files, like screenshot-to-file. Note that for write_avif, checking existance is used instead because avio_open does not support exclusive open mode.
* win32: resolve dropped shell links (Windows shortcuts)nanahi2024-03-191-1/+3
| | | | | When a shell link is dropped onto the mpv window, the file name will be replaced by the file name of its target so that the linked file is played.
* vo_gpu_next: make `dither-depth=auto` mean 8 bpc for non-d3d11 SDRllyyr2024-03-191-1/+5
| | | | | | | Fixes the issue described in https://github.com/mpv-player/mpv/issues/11862 for SDR files for non-d3d11 gpu-api. We currently don't have a smarter way to get the real on-the-wire bpc for other APIs, so this is the best that can be done.
* vulkan: remove color_depth stubllyyr2024-03-191-6/+0
| | | | Needed for the next commit
* vo_gpu_next: fix -Wembedded-directive warningnanahi2024-03-192-18/+19
| | | | warning: embedding a directive within macro arguments has undefined behavior
* video/out/gpu/spirv: fix warning: zero size arrays are an extensionnanahi2024-03-191-0/+1
|
* various: fix -Wold-style-declaration warningnanahi2024-03-195-6/+6
| | | | warning: `static' is not at beginning of declaration
* video/out/placebo/utils: fix -Wignored-qualifiers warningnanahi2024-03-191-1/+1
| | | | warning: type qualifiers ignored on function return type
* vo_gpu_next: don't render ASS subtitles at HDR colorspaceKacper Michajłow2024-03-181-1/+1
| | | | | | | | | | | | Upstream ASS specification says that all subtitles should be rendered with color primaries and transfer matching their associated video. But as expected after further discussion the decision has been made to fallback to SDR mode in case of HDR video. See-Also: https://github.com/libass/libass/blob/649a7c2e1fc6f4188ea1a89968560715800b883d/libass/ass_types.h#L233-L237 See-Also: libass/libass#297 See-Also: mpv-player#13381 Fixes: mpv-player#13673
* win32: remove all NC area on Windows 10 with --title-bar=noKacper Michajłow2024-03-181-3/+12
| | | | | | | | | Windows 10 top bar height cannot be adjusted individually when WS_CAPTION is enabled due to buggy DWM NC drawing behavior. The issue is fixed in Windows 11. To keep consistent window look remove the border on each side, but only on Windows 10.
* win32: add helper function to check Windows 10 build numberKacper Michajłow2024-03-181-8/+20
|
* win32: adjust top border offset when title bar is disabledKacper Michajłow2024-03-181-18/+52
| | | | | | | | | | | | | | | Windows 11 draws border regardless, so we are 1px off on window size, blending border with one line of video. Fix that by adding the border to our internal windows size calculation. Windows 10 on the other hand has a bug where specifying left and top NC area will trigger title bar drawn in full height always. Keep old behaviour in this case. Also while there is similar "visible" border there, it seems to be transparent on Windows 10. For high contrast themes, don't adjust title bar height and instead remove WS_CAPTION to have the same border all around the window, as DWM doesn't make borders invisible in this case.
* win32: add DWMWA_VISIBLE_FRAME_BORDER_THICKNESS definitionKacper Michajłow2024-03-181-1/+8
|
* win32: use dpi aware GetSystemMetricsForDpiKacper Michajłow2024-03-181-9/+19
|
* win32: update maximized state when leaving fullscreennanahi2024-03-181-6/+7
| | | | | If the window-maximized is set while in fullscreen, it needs to be applied when leaving fullscreen, as noted in the comment.
* win32: fix window maximized state after setting window sizenanahi2024-03-181-0/+20
| | | | | | | | | | | With runtime geometry change, currently it only results in a SetWindowPos call to resize the window. However, SetWindowPos doesn't change the window maximized state, so Windows still thinks that the window is maximized even though it no longer covers the whole workspace. This results in visual glitches, and if the window is dragged afterwards it's "restored" again. Fix this by correctly setting the window maximized state in this case.
* wayland_common: respect compositor's preferenced size on state changenanahi2024-03-171-4/+2