Bug 385026

Summary:	Pointer lock interferes with games
Product:	[Plasma] kwin	Reporter:	Sandeep <sandy.8925>
Component:	input	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	rickard.gerthsson
Priority:	NOR	Flags:	mgraesslin: Wayland+ mgraesslin: X11-
Version First Reported In:	5.10.95
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Sandeep 2017-09-24 19:16:22 UTC

KWin automatically locks the pointer for some games (I guess to prevent the pointer from escaping the window, so that relative mouse movement can work) - however, this causes problems in games like Left 4 Dead 2 and Jotun, when we access the game menu.

Here's what happens:
1) I tap Escape once, to pause the game and access the game menu
2) For some reason, KWin thinks the game menu is a separate window, and the pointer is locked to the game menu
3) I resume the game - and am unable to move the mouse in the game (whereas it worked fine before opening the menu)

The same also applies if we try to open the Steam overlay while in the game.

Can we turn off pointer lock setting somewhere, or manually override it and tell it which window to lock? Some kind of shortcut key to enable pointer lock manually for currently focused window would be nice. 

Is it possible to configure it to show the notice for a smaller period of time (1-2 seconds instead of 3-5 like it is now)?

Comment 1 Martin Flöser 2017-09-25 04:24:33 UTC

It is not KWin automatically locking the pointer. It is the application requesting it for each window. If it requests for a menu KWin will do so as that is what was requested. If that is wrong the bug is with the application.

Comment 2 Sandeep 2017-09-25 19:21:26 UTC

Well, when I say menu, it's not the usual context menu that you get when you use the right mouse button click.

It's more like a separate screen that shows game menu with options like settings, resume, quit etc.

Is there any way for me to capture these requests? If I build KWin debug build, are there any logs I can enable to find out if the app is requesting it a second time?

Comment 3 Martin Flöser 2017-09-26 18:32:51 UTC

You can be absolutely sure that the app is requesting the lock. KWin would not lock if it were not requested.

To figure out you can run with WAYLAND_DEBUG=1 environment variable, it will tell every request.

Comment 4 kde38 2018-08-16 13:38:12 UTC

Please remove pointer lock if you won't add a disable feature very soon. The lock behaviour is very limiting to the work flow.

Comment 5 Sandeep 2018-08-16 14:55:15 UTC

Actually, the bug was fixed in kwayland 5.48+.

If you upgrade to that and kwin 5.13.0+, the pointer lock problem is mostly solved.

Comment 6 kde38 2018-08-16 17:33:44 UTC

(In reply to Sandeep from comment #5)
> Actually, the bug was fixed in kwayland 5.48+.
> 
> If you upgrade to that and kwin 5.13.0+, the pointer lock problem is mostly
> solved.

I use kwayland 5.48 and kwin 5.13.4 under Solus.

Comment 7 Sandeep 2018-08-16 17:53:39 UTC

Are you facing this bug? https://bugs.kde.org/show_bug.cgi?id=388885

I still get that from time to time. The patch (https://phabricator.kde.org/D13466) to fix that is supposedly in kwin 5.13.1+, but kwin 5.13.1+ still exhibits that buggy behaviour from time to time.

I compiled kwin 5.13.3 with that patch, and that seemed to conclusively fix that problem for me.

Maybe you can try compiling 5.13.4 with that patch and see if it works for you.

Comment 8 kde38 2018-08-16 18:07:25 UTC

(In reply to Sandeep from comment #7)
> Are you facing this bug? https://bugs.kde.org/show_bug.cgi?id=388885
I don't think I have experienced that I am not able at to release the pointer lock.


> I still get that from time to time. The patch
> (https://phabricator.kde.org/D13466) to fix that is supposedly in kwin
> 5.13.1+, but kwin 5.13.1+ still exhibits that buggy behaviour from time to
> time.
> 
> I compiled kwin 5.13.3 with that patch, and that seemed to conclusively fix
> that problem for me.
> 
> Maybe you can try compiling 5.13.4 with that patch and see if it works for
> you.
Unfortunately I am not very knowledgeable about compiling.