[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 postix changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 Bug Janitor Service changed: What|Removed |Added Status|REPORTED|ASSIGNED Ever confirmed|0 |1 --- Comment #6 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2850 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 --- Comment #5 from David Redondo --- Can you escape on all sides? I noticed there's a bug that lets you sometimes escape the confinement on the top and left while right and bottom work correctly -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 David Redondo changed: What|Removed |Added CC||[email protected] --- Comment #4 from David Redondo --- Turns out there are multiple ways to grab your pointer; - GrabPointer has a grab_window parameter that grabs the window and a confine_to window to which the window is confined. - Additionally there is also a XIGrabDevice request. In the xserver if somebody is using the xinput request it goes into the same path but with confine_to not set (None). The xwayland path is only hooked into if we have a confinement and then will do a pointer constraints For exmaple Qt first tries xinput and then grabpointer without confinement so imo it would make sense to have a window rule to confine pointer to windows. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 --- Comment #3 from Akseli Lahtinen --- Something I noticed when it comes to this specific thing: When playing Splitgate in normal window mode (not fullscreen or fullscreen borderless), the mouse stays locked in the game. This may be the game engine doing this, but it may also be something else. My guess it's the game-engine itself since no other games have the same issue, but who knows.. If there's any way I can help to figure out where the problem could be, do share! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 Nate Graham changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 --- Comment #2 from Akseli Lahtinen --- > I'd like to understand the original bug better. Surely the X client is > grabbing the mouse, and we support pointer constraints. Unfortuntately even X client is having problems with some mouse constraints in some games, Splitgate being one. Could be that it's bug within the game as well. But, there are older games that also have this issue, which do not get updated anymore. However on X, the mouse starts "escaping" the screen only after switching windows once. On Wayland it can happen any time. I've tried to set force focus stealing prevention for the game window but that has not worked unfortunately. On X I solved the issue by making a very hacky bash script with xdotools. It's definitely not a good solution. > If and only if we need it what might work better is to have a window rule to > enable faux pointer constaints on that window. That would be perfect solution for my usecase! :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455993] Let user constrain cursor to one monitor (Wayland)
https://bugs.kde.org/show_bug.cgi?id=455993 David Edmundson changed: What|Removed |Added CC||[email protected] --- Comment #1 from David Edmundson --- The issue sounds relevant, I'm not sold of that approach. It's very hands-on for the user, both to enable and disable afterwards, you can't temporarily break etc, and it's a whole new code path in kwin. I'd like to understand the original bug better. Surely the X client is grabbing the mouse, and we support pointer constraints. It should "just work". We need to identify if anything is broken or if we can do anything smarter first. If and only if we need it what might work better is to have a window rule to enable faux pointer constaints on that window. -- You are receiving this mail because: You are watching all bug changes.
