GNOME Bugzilla – Bug 764852
Create configuration option for dwt (disable while typing)
Last modified: 2017-06-06 08:38:59 UTC
Created attachment 325672 [details] My proposal Since a while, libinput enables `dwt` by default. This is very annoying for playing games (especially first person stuff) you have to move the mouse and press keys at the same time. I suggest a "Disable while Typing" configuration option in gnome-control-settings, see attached screenshot. I'm working on that, I have already altered the gschema. Will post patches as soon as this starts to work.
Created attachment 325677 [details] [review] gsettings-desktop-schemas: patch [1/1] Add's the dwt-enabled setting in gconf.
(In reply to Ruben De Smet from comment #0) > Created attachment 325672 [details] > My proposal > > Since a while, libinput enables `dwt` by default. This is very annoying for > playing games (especially first person stuff) you have to move the mouse and > press keys at the same time. Moving a *mouse* shouldn't disable the keyboard. Is your mouse detected as a touchpad or something?
Review of attachment 325677 [details] [review]: We don't add configuration options to work-around bugs, sorry.
(In reply to Bastien Nocera from comment #2) > (In reply to Ruben De Smet from comment #0) > > Created attachment 325672 [details] > > My proposal > > > > Since a while, libinput enables `dwt` by default. This is very annoying for > > playing games (especially first person stuff) you have to move the mouse and > > press keys at the same time. > > Moving a *mouse* shouldn't disable the keyboard. Is your mouse detected as a > touchpad or something? Sorry, I meant to say *touchpad*, not *mouse*. Since a while, libinput enables `dwt` by default for *all* touchpads, and you cannot disable this.
A simple question for someone with knowledge on this topic: in what gnome project should the question get reflected? I currently have this: - gsettings-desktop-schemas contains the correct boolean for the dwt option - gnome-control-center contains the switch that is reflected in gsettings I thought the next step was to implement the correct libinput calls in gnome-settings-daemon, but apparently (correct me if I am wrong), there's only some schema stuff in gnome-settings-daemon, and now I have no clue where to bind on the gconf setting and put it into libinput. How does this work, exactly?
I found it, it's in mutter and I wrote the necessary code. Patches incoming...
Created attachment 325710 [details] [review] Adds the dwt control to gnome-control-center This patch sets the setting as described in patch 325677.
Created attachment 325711 [details] [review] Adds the dwt libinput and x11 control to mutter This patch lets mutter listen to the dwt-enabled setting and sends the correct events the correct touchpad via libinput or the X11 libinput setting.
Peter, can we support this use case without adding more configuration options?
As an aside: I thought of two other options: 1. - Design a standard communication protocol (freedesktop) to configure libinput via dbus (?) and get that implemented in GNOME (and KDE, and other DE's and WM's/compositors) - create a command line program that talks to GNOME and the other compositors via dbus to configure these settings 2. Have games and other programs requiring touchpad and keyboard interaction at the same time send a signal to gnome/other DE's (possibly via the same protocol as in 1.) I think that, on the long run, we need both 1. (at least the standard protocol) and 2. (via that dbus protocol) implemented on top of a manual configuration option, albeit for convenience for end-users playing games. Of course, I'm very open to other suggestions I didn't think of.
(In reply to Bastien Nocera from comment #9) > Peter, can we support this use case without adding more configuration > options? I haven't found a way. We're trying to only enable it for built-in touchpads and built-in keyboards but beyond that it's a guess what the current use-case is. libinput has that dwt option because we could not do palm detection reliably, on most touchpads we deal with a palm touch looks identical to a finger touch. I'm all ears for suggestions though, I hate having to expose this option.
The current use case is indeed a laptop with built-in keyboard and touchpad. Some of those people prefer the touchpad to an external mouse and a subset of those use their touchpad and keyboard at the same time.
(In reply to Ruben De Smet from comment #12) > The current use case is indeed a laptop with built-in keyboard and touchpad. > Some of those people prefer the touchpad to an external mouse and a subset > of those use their touchpad and keyboard at the same time. If gnome-shell (via mutter) automatically disabled "disable-while-typing" when there's a fullscreen window (eg. a game) would that be good enough? We already have a number of special cases for fullscreen applications like games in gnome-shell, so I think that not having a separate option would be preferable.
That would only solve part of the problem; some people (like me) play games or use Blender in windowed mode. But that would do something already indeed. Another suggestion: use everything I wrote, except for the gnome-control-center part (so mutter and gsettings-desktop-schemas), so that an extension can change the configuration option (like caffeine) or you can edit it manually in gconf. Would that be something? That would expose the option, but it's hidden away for power users. Then you can also add the game thing you mentioned, for some smoother use cases and non power users.
(In reply to Ruben De Smet from comment #14) > That would only solve part of the problem; some people (like me) play games > or use Blender in windowed mode. I think this is the crux of the matter here. Without some communication with the app, you can't know if "hold X while pointer events happen" is a bug or not. Someone who's typing in an editor may do that and require dwt, someone who's typing in blender merely triggers a shortcut and doesn't require dwt. In libinput, it's impossible to tell anyway but I think you'll find it extremely hard even within gnome shell. now, we *could* introduce some sort of protocol for apps to disable it on the fly or so, but I don't think it will cover the main required use-cases well enough and you'll end up with a need for some global option anyway.
Filed bug 764986 for the 95%-no configuration case.
Review of attachment 325677 [details] [review]: The commit message needs work as well. ::: schemas/org.gnome.desktop.peripherals.gschema.xml.in @@ +14,3 @@ <description>When disabled, touchpads that only support edge scrolling (and not 2-finger scrolling) will have that feature disabled.</description> </key> + <key name="dwt-enabled" type="b"> I don't like the shortened name. @@ +16,3 @@ + <key name="dwt-enabled" type="b"> + <default>true</default> + <summary>Whether disable while typing is enabled</summary> Please write "disable while typing" or disable-while-typing, so we understand that it's the name of the option. @@ +17,3 @@ + <default>true</default> + <summary>Whether disable while typing is enabled</summary> + <description>When enabled, touchpads that support disable while typing will disable the touchpad while typing.</description> Ditto.
Review of attachment 325710 [details] [review]: I don't want this in the Settings, at least for now.
Review of attachment 325711 [details] [review]: Again with "dwt".
Review of attachment 325677 [details] [review]: Note that the original setting is called "disable-while-typing" and was in gnome-settings-daemon. Look in data/org.gnome.settings-daemon.peripherals.gschema.xml.in.in to find better descriptions.
Roger that, I'll have a look this evening (GMT+1).
The control center in Gnome 3.16 had a "Disable while typing" checkbox in it. What changed which makes it no longer a good idea to have this option?
(In reply to wwijsman from comment #22) > The control center in Gnome 3.16 had a "Disable while typing" checkbox in > it. What changed which makes it no longer a good idea to have this option? We started using libinput, which implements "disable while typing" in such a way that it doesn't need to be configured.
Having dwt as an option (at least via gsettings) is vital indeed, for the use cases mentioned like fps games (e.g. minetest) or working in blender. As Gnome drops synaptics support, people should not have to resort to Windows for games for such reasons...
Created attachment 341683 [details] [review] schemas: Add "Disable while typing" touchpad setting Disable-while-typing is useful for the majority of cases, except for a select few applications that require using both touchpad and keyboard, such as games, and creativity applications which require pressing keys and moving the cursor.
Attachment 341683 [details] pushed as 4c5b1c1 - schemas: Add "Disable while typing" touchpad setting
Reassigning to mutter to actually implement the setting.
*** Bug 777494 has been marked as a duplicate of this bug. ***
*** Bug 781989 has been marked as a duplicate of this bug. ***
Why not put a simple flags in settings->mouse? And leave the user free to enable it, same as a click on the touchpad? I think I need to uninstall gnome/wayland for another couple of years.
Created attachment 351785 [details] [review] Adds disable while typing to mutter for x11 and wayland. This attachment addresses all previous issues with prior patches and fixes a few prior mistakes. It follows all implementation patterns of similar properties in mutter.
Review of attachment 351785 [details] [review]: The commit message should be formatted so that lines are not too long (i.e. try to make them not longer than 72 chars). Anyway, except from that and minor nits, this looks good to me. Want to update the patch or want me to amend the whitespace changes before pushing? ::: src/backends/native/meta-input-settings-native.c @@ +136,3 @@ + if (libinput_device_config_dwt_is_available (libinput_device)) + libinput_device_config_dwt_set_enabled (libinput_device, + enabled ? LIBINPUT_CONFIG_DWT_ENABLED : LIBINPUT_CONFIG_DWT_DISABLED); For coding style consistency with other places that does the same thing (see .._set_tap_enabled()), this should be: libinput_device_config_dwt_set_enabled (libinput_device, enabled ? LIBINPUT_CONFIG_DWT_ENABLED : LIBINPUT_CONFIG_DWT_DISABLED); ::: src/backends/x11/meta-input-settings-x11.c @@ +212,3 @@ +{ + guchar value = (enabled) ? 1 : 0; + We can actually test the availability of dwt via xf86-input-libinput (by checking the existance of the "Default" property), but that can be added later.
*** Bug 782859 has been marked as a duplicate of this bug. ***
Created attachment 352383 [details] [review] Patch for disable while typing in mutter, fixed coding style. I added the style fix you asked for! Everything else is fairly close to 72 characters but I emphasized fitting the current code style and readability over trying to get each line to 72. As far as I can tell all my additions should match current style. The reason I avoided the check in x11 is because change_property already detects if a property doesn't exist, Mutter only checks for availability explicitly if it is a setting that has multiple options (3 fingers, 4 fingers, etc.) from what I can see (look at tap_enabled for an example), and if by checking the default value you mean finding the value of 'default' and then checking if its truthy... that fails on systems on systems with a false default. If you mean checking that the property itself actually exists, as mentioned in my first point I'm fairly certain that change_property already checks that... so wouldn't that be a redundant check? I might be wrong on this, I'm no Mutter expert. Thank you so much for your time! If I didn't get the whitespace right please append a commit to fix it as you like. :)
(In reply to Evan Welsh from comment #34) > Created attachment 352383 [details] [review] [review] > Patch for disable while typing in mutter, fixed coding style. > > I added the style fix you asked for! Everything else is fairly close to 72 > characters but I emphasized fitting the current code style and readability > over trying to get each line to 72. As far as I can tell all my additions > should match current style. Actually the 72 char limit is about the commit message. Code has soft limit on 80 that is often not respected when it'd awkward to respect.
Created attachment 352427 [details] [review] Implements disable-while-typing in mutter. I misread your previous comment. I've reformatted the commit message so it fits into a 72 character line limit. Sorry about that!
Is there any workaround for stable (3.24) users on Wayland?
Review of attachment 352427 [details] [review]: lgtm.
(In reply to lastweakness from comment #37) > Is there any workaround for stable (3.24) users on Wayland? There is no work-around. With that said, it'll be part of the next 3.24.* release.
(In reply to Jonas Ådahl from comment #39) > (In reply to lastweakness from comment #37) > > Is there any workaround for stable (3.24) users on Wayland? > > There is no work-around. With that said, it'll be part of the next 3.24.* > release. Oh. Thanks. Guess i'll wait.
Comment on attachment 352427 [details] [review] Implements disable-while-typing in mutter. Attachment 352427 [details] pushed as 28b2add - Implements disable-while-typing in mutter.
Pushed to both gnome-3-24 and master, after fixing some whitespace issues (mostly trailing whitespaces not visible in the bugzilla review tool).
*** Bug 783454 has been marked as a duplicate of this bug. ***