Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

touchinput on wayland/sway broken after 0.38.0 #13985

Open
an0nfunc opened this issue Apr 25, 2024 · 4 comments
Open

touchinput on wayland/sway broken after 0.38.0 #13985

an0nfunc opened this issue Apr 25, 2024 · 4 comments
Labels

Comments

@an0nfunc
Copy link

an0nfunc commented Apr 25, 2024

OSD does not register touchinput on wayland after 0.38.0. I could bisect it to first bad commit a140d27. Reverting this commit fixes touchinput and restores 0.37.0 behavior.

Important Information

Provide following Information:

  • mpv version: 0.38.0
  • Linux Distribution and Version: Archlinux
  • Source of the mpv binary: repos
  • If known which version of mpv introduced the problem: 0.38.0 (or commit a140d27)
  • Window Manager and version: sway 1.9 + wlroots 0.17.2 + wayland 1.22.0
  • GPU model, driver and version: AMD igp

Reproduction steps

  1. run any build after a140d27
  2. try to use the osd with touchinput on wayland+sway

Expected behavior

Working touchinput on OSD, like in 0.37.0

Actual behavior

OSD shows up, but input does nothing.

mpv.log

@an0nfunc an0nfunc changed the title touchinput on wayland broken after 0.38.0 touchinput on wayland/sway broken after 0.38.0 Apr 25, 2024
@na-na-hi
Copy link
Contributor

Sway chooses to send pointer leave events just before touch down and pointer enter just after touch up. This results in the mouse being moved to the pointer position which is different from the last touch position. Reverting that commit leads to other bugs: clicking the mouse after performing a touch goes to the last touch position instead of the current mouse position.

The fundamental problem is that the mpv input system has no concept of touch inputs, so they interfere with mouse inputs. Without mpv treating mouse and touch inputs differently, this cannot be properly solved.

@an0nfunc
Copy link
Author

an0nfunc commented Apr 25, 2024

I wasn't suggesting reverting a140d27 as the way to solve this, just that it solves this particular regression (on sway) for reproducibility.

Is there a possibility to handle different WMs differently, e.g. by querying DESKTOP_SESSION? (although I agree that proper touch handling would obviously be preferable)

@na-na-hi
Copy link
Contributor

Is there a possibility to handle different WMs differently, e.g. by querying DESKTOP_SESSION?

I think this is not done on purpose. WM behaviors can change between versions so this is also improper. There are some special handlings in mpv where the Wayland protocol is underspecified, but not for this case where it's clear that mpv's current handling is incorrect.

There are other short-term solutions for this, but I'm not sure if it's worth the effort since they will be trashed when proper touch handling is in place.

@na-na-hi
Copy link
Contributor

na-na-hi commented May 1, 2024

#14003 implements proper multi-touch support, which gives scripts (like the OSC) a way to distinguish between mouse and touch events.

Note that the PR doesn't fix this issue by itself, since this arises from the fact that a mouse event on the top half of the window always immediately hides the OSC. But now I think the OSC can be modified so that it responds to touch differently to fix this issue: when anywhere on the window is touched, the OSC shows for a fixed time before it disappears, regardless of the mouse position. This makes sense since mobile video player touch UIs behave similarly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants