SUMMARY I'm unsure if this is a touchpad issue, a purely KWin + Wayland issue, or something else. But I'm almost certain I didn't have this issue previously under X, and it essentially breaks any full screen game that uses the cursor because most (all?) these games aren't able to exclusively lock the input device under Wayland. STEPS TO REPRODUCE 1. Enable "disable while typing" option in kcm_touchpad. 2. Launch a full screen application that takes input from the cursor. 3. Attempt to use the cursor while typing. OBSERVED RESULT Disable while typing prevents the cursor from moving. (Turning this feature off fixes the issue.) EXPECTED RESULT Full screen applications explicitly lock the cursor. It's certainly possible that there is a new Wayland protocol (or a draft) that would allow an application to request exclusive access to input devices, and maybe that would fix this. I don't know anything about that. But it would be a very big mistake (IMO) to close this as a bug in the applications. There are tons of legacy applications that will never get updates, and having to open the touchpad settings every single time you use one and temporarily change a setting is unreasonable. I'm *not* requesting that Plasma somehow give fullscreen applications exclusive input lock even if they don't request it under whatever protocol would be appropriate, I'm *only* requesting that it not activate the "disable while typing" feature for my touchpad in these cases. Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.2-arch1-1 (64-bit) Graphics Platform: Wayland
Are you attempting to move your cursor via the touchpad in game? If so your touchpad is being disabled while typing.
(In reply to fanzhuyifan from comment #1) > Are you attempting to move your cursor via the touchpad in game? If so your > touchpad is being disabled while typing. Yes - that's the specific issue I'm reporting here. This breaks virtually every full screen game that relies on a mouse / touchpad. This didn't happen before (probably because the games exclusively locked the input devices under X, but not Wayland?), and my reasoning is that since KWin does compositing for all windows under Wayland, Plasma should disable this setting for windows that are fullscreen.
The problem here is that we don't know if a full-screen window is a game or not. So the setting is pretty dumb and it can't figure out whether applying it to any given context makes sense or not. If you play video games, at the moment the safest thing is to disable the setting entirely. In principle we could make the feature auto-disable itself when in a fullscreen window, on the logic that it *might* be a game, but this might be unexpected or disruptive to people who don't play games. The warning I added for 6.2.0 might help, but clearly it isn't enough.
The issue is deeper than that - like many input features, this isn't actually something done by KWin, but by libinput. So this would kind of require implementing the feature in KWin first (which should be quite straight forward, but I haven't tried). If we had that though, we could do something about this in many cases. I can think of two approaches: 1. don't disable the touchpad if we detect the focused app is in the game category (in the .desktop file), or the Wayland content type is "game" - and you're not typing into a text field 2. only disable the touchpad if we know you're actually typing into a text field. This is trivial with Wayland apps, not sure it's feasible for X11 apps Neither is completely bullet proof, but I think with option 1 we could at least make the issue less severe.
My thinking was that since Plasma controls the setting, you could just turn it off in libinput and then turn it back on again when the program closes. I suppose there might be reasons not to do that, e.g. if KWin crashes or something? To the extent that libinput lacks support for compositors changing settings like this one on a temporary basis, that might arguably be a bug in libinput. I think there's a Wayland protocol that would solve this problem (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/110) but it looks to be stalled.