summaryrefslogtreecommitdiffstats
path: root/video/out/wayland_common.c
Commit message (Collapse)AuthorAgeFilesLines
* wayland_common: respect compositor's preferenced size on state changenanahi11 days1-4/+2
| | | | | | | | | | | Currently mpv always uses the previous window size when unmaximizing or exiting fullscreen. This disregards compositor's preferenced size in the configure event, resulting in wrong window size if changing window state and size are delivered in the same configure event. It's better to always respect the preferenced size instead, unless the state change is due to runtime geometry change, where we want to use our preference.
* wayland_common: always use the current geometry for prepare_resizenanahi11 days1-14/+12
| | | | | | | | | | | | | | | | | | | | In the xdg_toplevel_configure handler, in some cases the geometry is not equal to the width and height in the event. This can happen when runtime geometry change is requested (a new size is set), or in the case of wl->state_change || width == 0 || height == 0 (the old size is used). However, prepare_resize always uses the width and height in the event and not the corrected geometry here. This causes xdg_surface_set_window_geometry using the wrong value resulting in wrong size of window decoration. Amusingly, the debug message right above it uses the correct size. Fix this by using the updated geometry size instead. Since now all prepare_resize have parameters of 0, the width and height parameters are no longer needed. Fixes: 828dd65ef84b4d8e95e70752b9eb0833909d1d23
* wayland_common: move WAYLAND_DISPLAY check above vo_wayland_state initDudemanguy2024-03-131-3/+3
| | | | | | | | Segfaults otherwise on uninit because some objects are created while others are not. Move it to the very top since the purpose of this is to skip wayland initialization entirely while autoprobing. Fixes f6f1721101e299b0989a631213375da73db719a2.
* wayland_common: require WAYLAND_DISPLAY to be set for initializationnanahi2024-03-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Currently, Wayland is above X11 and DRM in probe order. The success of automatic probing depends on the fact that unsuitable backends would fail to initialize. For example, X11 backend (which uses Xlib) fails to initialize if DISPLAY environment variable is not set, so starting mpv in VT console will pick the DRM backend as expected, even when an X server is running in another VT. However, libwayland-client used by the Wayland backend has the "helpful" behavior of falling back to "wayland-0" if WAYLAND_DISPLAY is not set. This breaks autoprobing if mpv is started from X server or VT console while a running Wayland compositor running in another VT (or even running as an X client) is using "wayland-0" for protocol socket name: mpv will start playing in the Wayland compsitor instead of using the X11 or DRM backends. Similar to DISPLAY for X server, We should consider exporting WAYLAND_DISPLAY to child processes the responsibility of Wayland compositors, and any compositor not doing this should be considered broken. Thus we now require WAYLAND_DISPLAY to be set for the backend initialization to succeed to make sure that autoprobing works as intended.
* wayland: always rescale geometry if in a fullscreen/maximized stateDudemanguy2024-03-091-1/+1
| | | | | | | | | | | | | | | | | This should only be a problem during initialization. If in a multi-monitor setup, mpv guesses the wrong scale value and the user passes --fs, the scaled size will be wrong and you have to unfullscreen and fullscreen again to fix it. This is because rescale geometry won't do anything if the value of hidpi-window-scale is false (the default) so the geometry is never rescaled to the correct value thus the wrong size. Normally, mpv will just correct itself after subsequent events occur but because it is considered a locked size (as it should be), we avoid doing any other resizing events thus it never gets corrected. Fix this by just always rescaling the geometry in the locked size case. It shouldn't matter elsewhere because mpv will always have the correct scale value and the possibility of having the wrong one is only possible on startup. Fixes ded181f642bc8915e3569d718d404e915cb62c27
* wayland_common: fix pointer serial conflictnanahi2024-03-051-8/+9
| | | | | | | | | | | | c2129c18f8ecac4133aec59526434ad10f7f6896 saves the button down serial to pointer_serial of the seat so that it can be used for window dragging later. However, this overwrites the serial saved at the enter event. Since the serial in wl_pointer_set_cursor must be the latest wl_pointer_enter serial number sent to the client, if a button down serial overwrites that, setting cursor no longer works until the cursor enters the window next time. Fix this by using separate serials for these two types of events.
* wayland: fix missing lround in cursor surfaceDudemanguy2024-03-041-1/+1
| | | | Missed in f0a6578259f508a8863afcf9a1487872d7ae1878.
* wayland: guess the first hidpi frame betterDudemanguy2024-03-041-1/+7
| | | | | | | | | | | | | | | | 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: toplevel resize fixesnanahi2024-03-011-5/+7
| | | | | | Explicitly send an UP event after the client finishes a resize for touch event, don't resize if locked_size is set for touch event, and use the correct type for resize edges.
* wayland_common: implement VOCTRL_BEGIN_DRAGGINGnanahi2024-03-011-14/+37
| | | | | | 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 initialization order issue with protocolssfan52024-02-291-5/+7
| | | | | | This broke DND under (apparently) GNOME and KWin, but not sway. fixes: 2274311b259b7b03e3764ab4c21d69988b70a337
* wayland_common: fix DND read error handlingsfan52024-02-291-7/+17
|
* wayland_common: read DND data in larger chunkssfan52024-02-291-1/+1
|
* wayland_common: log if DND failssfan52024-02-291-0/+2
| | | | | This can happen if the compositor or applications don't behave correctly, so let the user know to aid debugging.
* wayland_common: free DND resources on shutdown and errorsfan52024-02-291-9/+19
| | | | This leaked only in edge cases, if at all.
* wayland: drop some unneeded curly braces (no-op)Dudemanguy2024-02-271-20/+10
| | | | | | Not sure why all of these single line if's were being braced. Probably some cargo cult from years ago but might as well fix it now since it's bothering me.
* wayland: drop buffer scale for cursor as wellDudemanguy2024-02-271-7/+9
| | | | | | | | | | | | | | 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-4/+4
| | | | Makes it clearer.
* wayland: fix check for set_surface_scalingDudemanguy2024-02-271-6/+3
| | | | | | | | | We don't want to use this if we have fractional scaling or version 6 of the wl_surface interface which has a preferred buffer scale event which is superior to this. We were checking in the important place (surface entrance events) but not technically in the output. So just move the conditional to set_surface_scaling itself. Also through the VO_EVENT_DPI in there for convenience.
* wayland: remove old sway/wlroots hackDudemanguy2024-02-261-9/+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.
* input: add insert-next support for drag-and-dropDavid Vaughan2024-02-261-2/+8
| | | | | | | This commit adds a DND_INSERT_NEXT action option for drag-and-drop, allows for selecting it through the --drag-and-drop=insert-next option, and adds the necessary plumbing to make that happen when something is dragged onto the player.
* player/command: handle runtime toggling of hidpi-window-scaleDudemanguy2024-02-241-2/+0
| | | | | | | Wayland was the only backend that attempted this, but it can be done in a centralized place for anything that supports this. hidpi-window-scale is just the same as a normal window scale but with the OS DPI as the factor.
* wayland_common: update pointer serial on pointer_enterJulian Orth2024-02-181-0/+1
|
* wayland_common: drop shape device check when spawning cursornanahi2024-02-171-9/+2
| | | | | | 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-4/+14
| | | | | 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-17/+20
| | | | | 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-40/+43
| | | | | Avoids modifiers from mulitple seats from interfering with each other and messing up xkb states.
* wayland_common: set cursor visibility for all seats for voctrlnanahi2024-02-171-3/+22
| | | | | | For VOCTRL_SET_CURSOR_VISIBILITY, set cursors visibility for all seats. The return is VO_NOTAVAIL is none of the seats have cursor, and VO_FALSE if setting visibility failed for at least one seat.
* wayland_common: handle removal of seatsnanahi2024-02-171-2/+13
|
* wayland_common: prevent cursor_seat stale referencenanahi2024-02-171-0/+1
| | | | Set it to NULL on vo uninit.
* wayland_common: handle cursor_shape_device per seatnanahi2024-02-171-26/+28
| | | | | | 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: drop unnecessary xdg_toplevel null checknanahi2024-02-171-11/+1
| | | | | The vo init already fails if xdg_toplevel creation fails, so these checks after the vo is initialized is unnecessary.
* wayland_common: implement multi-seat supportnanahi2024-02-171-86/+139
| | | | | | | | | | | | | | | | | | | | 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: indentation nitnanahi2024-02-171-1/+1
|
* wayland: don't press keys again when releasing modifiersGuido Cella2024-02-111-0/+6
| | | | | | | | | | | | | | | | | | Since 1f8013ff3f, if you release a modifier before a regular key on Wayland, that key gets immediately pressed again because keyboard_handle_modifiers() calls mp_input_put_key() regardless of whether a modifier is pressed or released, e.g. if you press Ctrl+s it easy to take an another screenshot with s by accident. Fix this by releasing keys when releasing modifiers. Ideally, releasing the modifier should input the key alone after --input-ar-delay, while this patch disables it forever, e.g. on X11 if you type something in the console, hold Ctrl+h, and release Ctrl, it starts typing h instead of deleting characters. This doesn't work because keyboard_handle_key() is only called when you first press a key, while on X11 KeyPress keeps getting sent as you hold down the key. But this difference in behavior between X11 and Wayland can also be reproduced with GTK and Qt applications, so I guess this is acceptable.
* wayland: set current_output on surface leave if applicableDudemanguy2024-02-081-4/+4
| | | | | | | | | | | | | | | | | | | When the mpv surface leaves the output, we no longer mark it as the current output. However, this implicitly depends on there being a preceding surface entrance event to a different output. This is not necessarily the case. Consider moving the window from monitor 1, to monitor 1-2, and then back to 1 again. mpv gets the entrance event to monitor 2 and sets that as the current output to work off of. Then when you move back to only monitor 1, it removes monitor 2 from the current output. However, monitor 1 is not updated again as the current output because there is not a new surface entrance event in this case (the window never left). So the numbers that mpv's core is using are incorrect and for the wrong monitor. Luckily, we already keep track of what outputs the mpv surface is currently on no matter how many there are so it is simply a matter of setting current output again in the leave event if we have a different output that has the mpv surface. Ref: https://github.com/swaywm/sway/issues/7932
* wayland_common: warn if scrolling will be brokennanahi2024-02-041-0/+3
| | | | | | Since the scroll event handler is moved to wl_pointer_frame, version 5 of wl_seat is required. Warn that scrolling is broken if the compositor doesn't support that verison.
* wayland_common: add touch listener boilerplatenanahi2024-02-041-0/+12
| | | | Required if seat version >=6 is used.
* wayland_common: prefer axis_value120 if supportednanahi2024-02-041-15/+90
| | | | | Prefer axis_value120 for high resolution scrolling if supported, which matches the existing win32 behavior.
* wayland_common: properly handle high resolution scrollingnanahi2024-02-041-1/+6
| | | | | | | | | | | Commit f54ad8eb055771a080f079964504cb0f32fc4014 broke high resolution scrolling because one logical mouse click is generated for every scroll event, no matter the magnitude. This makes scrolling on trackpad way too fast. Revert the axis scaling change in that commit and clamp the resulting value between -1 and 1 to make sure mouse wheel scrolling works as intended on compositors which send a value larger than 10 for these events.
* wayland: look for "default" cursor as well as "left_ptr"Dudemanguy2024-02-011-2/+5
| | | | | Some themes are apparently getting rid of "left_ptr" and using the cursor spec names instead. Check for "default" as well. Fixes #13376.
* vo_dmabuf_wayland: scale smarter in hidpi situationsDudemanguy2024-01-271-8/+5
| | | | | | | | | | | | | | | | | | 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: don't rescale dimensions if hidpi-window-scale is disabledDudemanguy2024-01-271-0/+3
| | | | | | If the scaling value changed for some reason, the window geometry would be recalculated with the new scaling even if this option was disabled. Properly ignore it.
* wayland: drop buffer_scale use for viewporterDudemanguy2024-01-271-17/+18
| | | | | | | | | | | | | | | | | | | 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_common: guard against negative configure sizesnanahi2024-01-191-0/+5
| | | | | | Negative values are nonsense to mpv, and can cause protocol error afterwards, like xdg_surface::set_window_geometry which doesn't accept negative values. Treat any negative values as zero (client determines size) for now.
* wayland: accept active modifiers even if they aren't physically heldllyyr2024-01-131-1/+1
| | | | | We don't care about the physical state of keys, only if they are effective or not and whether they should affect key processing.
* wayland: don't ignore key modifiers if they were consumedllyyr2024-01-131-1/+1
| | | | | | | | | | According to the xkbcommon docs, `xkb_state_mod_index_is_consumed` is true when a modifier *may affect* key translation. A key modifier may be consumed but not be active. See xkb documentation for this function for further details. This breaks key modifiers in cases where L_Shift+R_Shift for example is used to change keyboard layout with `xkb_options grp:shifts_toggle`. Instead, replace it with a simple check for a valid modifier.
* input: add missing forward media keynanahi2023-12-061-1/+2
| | | | | | | | | XF86Back and XF86Forward are mostly used to navigate file and web browsers to go back/forward in history. XF86Forward isn't recognized right now, so add it. Because XF86AudioForward already takes the "FORWARD" name, rename the browse keys to GO_BACK and GO_FORWARD instead.
* wayland: simplify reading dataKacper Michajłow2023-11-281-15/+10
| | | | | | | - read directly to bstr - use talloc for OOM checks - don't parent temporary allocation - don't check for NULL buffer after already writting to it
* wayland: fix shift+tab keyboard inputChristoph Heinrich2023-11-111-4/+4
| | | | | When pressing shift+tab we get 0xfe20 instead of 0xff09, which corresponds to the XKB_KEY_ISO_Left_Tab define.
* wayland: obey initial size hints set by the compositorDudemanguy2023-11-101-10/+16
| | | | | | | | | 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: don't sleep 1ms always when requested time is in the pastKacper Michajłow2023-11-091-1/+1
| | | | | | | | | | | | | | Fixes a899e14b which changed clamp from 0 to 1 ms which effectivelly introduced 1ms sleep always, even if requested until_time_ns is in the past and should request 0 timeout. While at it also fix mp_poll wrapper to respect negative timeout which should mean infinite wait. Also keep the 37d6604 behaviour for very short timeouts, but round only the ones > 100us, anything else is 0. Fixes: a899e14b
* present_sync: only save as many entries as the swapchain depthDudemanguy2023-11-071-1/+1
| | | | | | Saving more than the swapchain depth is just wasteful. We can just save a copy of the vo_opts here and check the value whenever we're updating values.
* vo: replace max swapchain depth magic numberDudemanguy2023-11-071-2/+2
|
* wayland: improve wl_output guessing before mpv window is mappedDudemanguy2023-11-061-4/+5
| | | | | | | | | | | | | | | | | | | | There's some geometry-related things that mpv has to calculate before the window is actually mapped onto the screen in wayland. But there's no way to know which output the window will end up on before it happens, so it's possible to calculate it using the wrong values. mpv corrects itself later when the surface event happens, but making the initial guess work better can help in certain cases. find_output is the only thing that needs to be changed here. Its main purpose is to grab the right output based on user settings when we're trying to full screen and giving a fallback in case we don't have wl->current_output yet. The x11 code already does something similar, so we're basically just copying it. Allow user settings like --screen and --screen-name to influence the initial wl_output guess. Those options won't actually place the window on that specific screen since we can't do that in wayland, but if the user knows where the window will end up befo