summaryrefslogtreecommitdiffstats
path: root/video/out/wayland_common.h
Commit message (Collapse)AuthorAgeFilesLines
* wayland: only perform a rescale if window is on one outputDudemanguy11 days1-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* wayland: enforce a state change after a reconfigureDudemanguy12 days1-0/+1
| | | | | | | | 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
* wayland: guess the first hidpi frame betterDudemanguy2024-03-041-0/+1
| | | | | | | | | | | | | | | | It's been a longstanding issue in wayland* that the first frame on a hidpi screen will have wrong scaling. A well behaved client immediately corrects this, but it's noticeable and also can affect window placement due to the way resizng works. Preferred scale from the fractional protocol and preferred buffer scale can actually solve this problem. It depends on compositors mostly, but one could simply send the event before the client maps its surface so it knows what the correct scale is in the first place. I'm not sure if any compositors currently behave like this (sway seems to still require the client to render before sending any scaling information at least), but it makes to sense to account for this possibility. *: https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
* wayland_common: implement VOCTRL_BEGIN_DRAGGINGnanahi2024-03-011-0/+3
| | | | | | This allows begin-vo-dragging command to initialize a vo dragging request for wayland. The last mouse button press seat and serial is used for the request if it is not consumed by interactive resizing.
* wayland_common: fix type of dnd_actionsfan52024-02-291-1/+1
| | | | | The default value of -1 and comparisons >= 0 only work properly with an int type.
* wayland: drop buffer scale for cursor as wellDudemanguy2024-02-271-0/+1
| | | | | | | | | | | | | | Could have been done in e32554cd570d984efb712a7214a40237233a3cea, but I skipped it there. However, using viewporter is actually a win here. There's been a longstanding issue in upstream wayland* exactly related to this. I even forgot about cd7a7a1de8d8bffa05170befef25b251711c994a which was made for this exactly problem and explains the random spawn_cursor calls. Anyways, just not using buffer scale and instead scaling the cursor surface via viewporter works just fine and completely sidesteps this problem. This means we can drop the random looking spawn_cursor calls and some additional checks. *: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
* wayland: rename configured to geometry_configured (no-op)Dudemanguy2024-02-271-1/+1
| | | | Makes it clearer.
* wayland: remove old sway/wlroots hackDudemanguy2024-02-261-2/+0
| | | | | | | | | | | | It's actually been like this for years, but wlroots doesn't keep track of resizes a client does independent of the compositor. When using sway, this leads to weird behavior with floating clients resizing themselves back to the old size if you unfocus it. mpv has been working around this for a long time, but it's really annoying to selectively ignore events based on a weird heuristic. Since Sway finally fixed this bug, let's go ahead and drop this crap. Note that other wlroots compositors may possibly experience a regression if they didn't correct for this like sway does, but it's for their own good.
* wayland_common: drop shape device check when spawning cursornanahi2024-02-171-3/+0
| | | | | | It's only necessary to check the existance of cursor_shape_manager. Also drop the pointer check to handle multi-seat since a removed seat sets the cursor_seat to NULL.
* wayland_common: properly determine has_keyboard_inputnanahi2024-02-171-1/+0
| | | | | Track has_keyboard_input per seat and consider mpv having keyboard input if at least one seat has keyboard input.
* wayland_common: handle scroll accumulation for each seatnanahi2024-02-171-5/+0
| | | | | Since it's needed to determine whether an axis event has axis_value120, do this per seat to avoid interference between seats.
* wayland_common: handle keyboard state per seatnanahi2024-02-171-5/+0
| | | | | Avoids modifiers from mulitple seats from interfering with each other and messing up xkb states.
* wayland_common: handle cursor_shape_device per seatnanahi2024-02-171-3/+3
| | | | | | The cursor_shape_device is per pointer, which is per seat. Handle it together with other seat objects. This in turn also handles cursor visibility per seat.
* wayland_common: implement multi-seat supportnanahi2024-02-171-5/+2
| | | | | | | | | | | | | | | | | | | | On a multi-seat setup, wl_registry_global advertises wl_seat multiple times, one for each seat. if wl->seat is already set, the previous value will be overwritten, preventing it from being freed. Additionally, if the latter seat doesn't have the capabilities of the former seat, the keyboard/pointer/touch input devices will be destroyed because the current wl_seat_capabilities doesn't distinguish between different seats. This casues keyboard/pointer/touch not working if the latter seat has no such capabilities. Fix this by implementing multi-seat support. This allows receiving inputs from all devices on all seats. All seat-specific objects (wl_keyboard/pointer/touch, wl_data_device) are grouped with their respective seats so they can be managed together. Note that currently inputs from all seats are interleaved with each other and modify the same global input states.
* wayland_common: prefer axis_value120 if supportednanahi2024-02-041-0/+5
| | | | | Prefer axis_value120 for high resolution scrolling if supported, which matches the existing win32 behavior.
* vo_dmabuf_wayland: scale smarter in hidpi situationsDudemanguy2024-01-271-1/+0
| | | | | | | | | | | | | | | | | | Previously, all scaling was forced to 1 with this vo and all coordinates were calculated as if the scale was 1. This works since viewport relies on the compositor completely for scaling so it doesn't really matter if we don't draw directly to the correct size since the compositor will just scale the rest for us. This does have some downsides however since the OSD text might not be drawn at the actual resolution of the final size of the video. We can instead handle this by getting rid of the dmabuf_wayland specific scaling logic and using the same values as everything else. In the resize in vo_dmabuf_wayland, we just need to adjust the viewport destination calls so they go to the wayland local coordinates and not the physical ones. This should ensure that vo_dmabuf_wayland directly goes to the desired size and the compositor doesn't need to operate on it after the fact.
* wayland: drop buffer_scale use for viewporterDudemanguy2024-01-271-1/+1
| | | | | | | | | | | | | | | | | | | The core wayland protocol way of handling scaling is to use the buffer_scale mechanism. But this sucks in several ways for reasons I won't list here and fractional scaling rightly avoids this altogether and uses a buffer_scale of 1 (i.e. not setting it) along with viewporter. When originally implemented, this was only specifically used when the fractional scale protocol was available, but we actually can use it as a full replacement instead. This means that mpv now hard requires viewporter, but this protocol is supported by everyone and is one of the few that is actually stable. How it works is the same regardless of fractional scaling or not. When the compositor has a scale value not equal to 1, it will always scale the client by that factor (unless you set buffer_scale). What we do here is pass a viewporter size that exactly undos the compositor-side scale (sans a possible rounding error). So what we are left with is just the exactly physical pixels we want to display. Fixes #13316.
* wayland: obey initial size hints set by the compositorDudemanguy2023-11-101-1/+3
| | | | | | | | | In the past, this worked by accident because the initial startup was racy and sometimes the initial firing of handle_toplevel_config would happen after reconfig. Since we now properly wait on all compositor events we can save the initial size hint that is given to us and try to use that as the window-size/geometry provided the --autofit/geometry options aren't explictly set. Fixes #11134.
* 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.
* wayland_common: remove questionable gcd impl and global statesfan52023-07-191-1/+0
|
* wayland: don't treat tiled and maximized windows the sameDudemanguy2023-07-191-0/+1
| | | | | | | | | | | | mpv has historically always treated the various tiled states in xdg-shell as maximized (probably because it was easier). Well it turns out that there are some tiling compositors (hyprland) that allow tiled windows to maximize themselves. This can lead to some scenarios where mpv ends up doing a maximize on hyprland which actually works since it's not a no-op like on sway. Fix this by separating out the tiled state from maximize. It works mostly the same, but the main difference is that there's no request to tile yourself like there is with maximize. Should fix #11954.
* wayland: add locked_size convenience shorthandDudemanguy2023-07-191-0/+1
| | | | | | | There's a lot of checks that are along the lines of !maximized && !minimized or vice versa. Make a locked_size boolean and store the value of this in here to avoid writing long lines since the next commit will add yet another condition to this.
* wayland: handle modifier keys correctlyDudemanguy2023-07-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't know why we've been doing this wrong for so long or how I didn't notice until now. Wayland specifically has an event for handling modifiers. We even named it "keyboard_handle_modifiers" in the code. What we should do is just get the modifier and save it after the xkb state is updated. Then later if the user does something else (press another key or clicks the mouse button), the saved modifier key is applied. If you let go of the modifier at any point, the xkb will just update its state again and we save a 0 again here (i.e. no modifier). There is one bit of an edge case however. If a key is pressed BEFORE the modifier, then we have to handle the mp_input_put_key in the modifier event instead since the ordering is not guarenteed. What we do here is keep track of the mpkey as well as the mpmod. However if we are unable to find a matching mpkey and the key state is pressed down, assume it's a modifery key that was pressed and don't update mpkey. That way whenever the modifier event does happen, it can correctly handle this and we know that the keys must be pressed down if we end up there in the code path. As another fun historical note, the xkb_keysym_to_utf8 line was actually written by wm4 himself in 460ef9c7a4bd2527f7f17eb8c95eeff3b67455f8 nearly 10 years ago. As the commit shows, it was clearly intended to handle modifiers (if lookupkey finds nothing, then try to find a mod instead). Of course, this is extremely dated and wayland hasn't worked like that in ages. This branch never actually did anything, and thus we'll remove it here along with modifier lookup changes. This solves bizarre issues with modifiers not working with random keys while working fine with others (don't ask me why). Fixes #10286 and fixes #11945.
* vo_dmabuf_wayland: add osd supportDudemanguy2023-07-121-0/+3
| | | | | | | | | | | | | | | | | | This adds osd support via shm buffers using a similar approach that the normal buffers do, but it differs in a few key areas. One thing to note is that sway and weston actually handle this extremely differently which required all the abstractions here. In particular, weston does not cope well with destroying the wl_buffer from shm outside of the release handler at all (i.e. it segfaults). The workaround here is to simply attach a NULL to the osd surface and do a surface commit before we destroy the buffers. This is reasonable enough and seems to work well although it's pretty weird. Sway is more straightforward although it actually releases the osd buffer when the window goes out of sight. Also, I found that it doesn't always release every buffer before you close it unlike weston seems to do which is part of the reason all this bookkeeping is required. I don't know if there's any other compositor out there that can possibly handle vo_dmabuf_wayland right now, but suffering through these two is good enough for now I think.
* wayland: add cursor-shape-v1 supportDudemanguy2023-07-091-0/+5
| | | | | | This protocol no longer requires us to draw a separate cursor surface and all of that horrible stuff. We can just ask the compositor for the default cursor instead since that's literally all mpv cares about.
* vo_dmabuf_wayland: drop linux-dmabuf-v2 (again)Dudemanguy2023-06-161-4/+0
| | | | | | It was done once before but later reverted for testing reasons. This time it's permanent though since I can test this VO on ARM and with an up to date system.
* wayland: bump wayland-protocols to 1.25Dudemanguy2023-06-161-2/+1
| | | | | 1.27 would have been nicer but ubuntu 22.04 is on 1.25 so we'll just compromise.
* wayland: use correct x/y coordinates for the cursorDudemanguy2023-03-081-2/+0
| | | | | | | | | | | | | While adding fractional scale support, the coordinates for wayland changed to always include the scaling parameter. The pointer stuff actually did too. However, the check_for_resize function used the unscaled, local surface coordinates. Likely, it was neccesary at the time since wl->geometry used to report unscaled coordinates. In light of that, we can just simply use mouse_x/y instead for this function to make it work correctly with the right/bottom edges. mouse_unscaled becomes completely unneccesary, so just drop it. Some minor style changes included just because.
* wayland: request frame callbacks on the topmost surfaceDaniel van Vugt2023-02-281-0/+1
| | | | | | | | | | | | Which is wl->video_surface for vo_dmabuf_wayland. Listening on wl->surface results in freezes if it is occluded and culled by the compositor. Which mutter does, and the wl_surface::frame spec warns about: > A server should avoid signaling the frame callbacks if the > surface is not visible in any way, e.g. the surface is off-screen, > or completely obscured by other opaque surfaces.
* wayland: deduplicate and cache detection of dmabuf-waylandDaniel van Vugt2023-02-281-0/+1
|
* wayland: use bool type for alpha framebuffer trackingRay Smith2023-02-281-1/+1
| | | | | | | | | ra_ctx_opts.want_alpha and vo_wayland_set_opaque_region's alpha argument are only used as bool but both are ints. Particularly for the function argument, passing a 0 or 1 is confusing - at first glance it looks like you're specifying an alpha value of 0 or 1. Since they're only used as bools, make them bools.
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-1/+1
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* Revert "vo_dmabuf_wayland: drop support for linux-dmabuf-v2"Dudemanguy2023-02-181-1/+4
| | | | | | | | | | | This was originally dropped because it was thought to be unneeded at the time, but at least some devices (rockchip) apparently are still on old compositors that use linux-dmabuf v2. It's not much code, and for testing purposes it's good to have around since it's hard to test drmprime otherwise. Some minor additions are here to support the newly added vaapi-format mapping in v2 of the protocol. This reverts commit a5b9d529eec8d4bb6fc858143337c3573ec8afd0.
* vo_dmabuf_wayland: reject hw formats not supported by compositorAaron Boxer2023-02-111-1/+7
|
* wayland: add wp-fractional-scale-v1 supportDudemanguy2023-01-241-1/+7
| | | | | | | | | | | | | This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
* wayland: rewrite geometry and scaling handlingDudemanguy2023-01-241-1/+0
| | | | | | | | | This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
* wayland: store presentation feedbacks in a poolDudemanguy2023-01-131-1/+1
| | | | | | | | | Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
* Revert "wayland: dispatch and wait for compositor events in uninit"Dudemanguy2023-01-131-0/+1
| | | | | | | | | | | This ended up being a bad idea. The problem is that it introduces ordering when destroying events (something we weren't worried about before) and Lynne pointed out a problem with the callback not also being destroyed before the surface in IRC. Just undo this and go with a different approach (next commit). P.S. the wayland_dispatch_events name change is kept though because I like that better. This reverts commit aa8ddfcdf30c4ffb38f3ec5d6663bbabf0b7b4df.
* vo_dmabuf_wayland: drop support for linux-dmabuf-v2Dudemanguy2023-01-121-4/+0
| | | | | | | | | The only real reason this was ever supported is because it was dramatically simpler than v4, so it was put in as an initial implementation. Later, v4 support was added and we left v2 for compatibility, but let's just drop it. Compositors all use v4 nowadays, and v2 is significantly limited (no modifier support for example). It's better to just remove this dead code for simplicity.
* wayland: make vo_wayland_reconfig a boolDudemanguy2023-01-081-1/+1
| | | | | | This was already returning true/false but the type was int. Also simplify a few places in the wayland contexts where we can just return the value of this function instead of doing redundant checks.
* vo: change vo_platform_init to boolDudemanguy2023-01-081-1/+1
| | | | | | | | There's several functions that are used for initializing mpv on a certain platform (x11, wayland, etc.). These currently are all int, but they actually return 1 and 0 like a boolean. This gets a bit confusing because actual vo preinit functions return 0 and -1 instead. Just make these all bool instead and return true/false to make it clearer.
* wayland: dispatch and wait for compositor events in uninitDudemanguy2023-01-031-1/+0
| | | | | | | | | | Similar to some other issues we've had with unprocessed compositor events. When quitting mpv, there's two things we should be doing: dispatching any last minute wayland events and then waiting for a compositor reply. Luckily, there's already an internal helper for this (renamed to wayland_dispatch_events for consistency) that we can use. All of the special casing of wl->feedback becomes unneccesary and we can remove this from vo_wayland_state with this method. Fixes #110022.
* vo_dmabuf_wayland: use single-pixel-buffer-v1LaserEyess2022-11-201-0/+4
| | | | | | | The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
* wayland: add support for content-type protocolDudemanguy2022-11-151-0/+7
| | | | | | | | | | | | | | | | | | | | The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
* build: add an additional check for wayland-protocols 1.24Dudemanguy2022-10-291-1/+2
| | | | | | | | | | | | | | | | | 666cb91cf12a4f8b42087530104513b0fc4ba16d added support for v4 of the dmabuf protocol. This was meant to be optional and the fallback support for the old v2 (dates back to 2017[0] well before the 1.15 wayland-protocol version we depend on) was maintained. However, v4 added several new functions and structs that of course aren't defined in old protocol versions so naturally this breaks the build on those systems. Since this is just a niche feature and not really critical to overall wayland support in mpv, just give in and add another check in the build system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf depends on wayland protocols 1-24[1], so go ahead and make that our new check. Fixes #10807. [0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4 [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
* video/out/wayland_common: adjust decoration disagreement log levelJan Ekström2022-10-271-1/+0
| | | | | | | | | | | | | Originally, I considered warning once to be useful for figuring out whether the change in logic regarding resetting requested mode actually fixed the reported issue or not, but alas not everyone was happy with that decision. Thus the log level will always be debug. This enables us to lose one level of indent as well as a variable, which is always positive. Additionally, make the message more explicit regarding what could possibly be implied by the mismatch, as it seems like this was not always clear.
* video/out/wayland_common: clear decoration request even if compositor disagreesJan Ekström2022-10-261-0/+1
| | | | | | | | | Otherwise mpv and the compositor can end up in an eternal loop where mpv requests one mode, and compositor tells that the mode is not that (and will most likely not change). Additionally, log these mismatches - first time as a warning, and later as debug logging.
* wayland: bump dmabuf protocol to version 4Emmanuel Gil Peyrot2022-10-261-1/+5
|