For Linux libinput “Disable While Typing” (DWT) problems, this page claims libinput will only use the DWT setting if the keyboard and touchpad are either both identified as internal devices, or are both identified as the same device. (The assumption is that if the keyboard and touchpad are separate USB devices, then they won’t be in a fixed position where palm rejection is problem.) If they are identified as different devices, a local device quirk to identify them as internal might help.
4 Likes
Under KDE NEon, while on travel, I have the enabled palm-detection and disable touchpad while typing.
(On my workstation configuration is different reason the pics don’t show it as active). Will be able to tell how it works when I have the FW 16.
1 Like
Yes! Thank you gcf! That “How to Diagnose Disable-While-Typing Issues” link was just what I needed. The final " What if DWT Doesn’t Work?" section worked. I followed its directions to create a quirks file to set the touchpad and keyboard as “internal” devices the palm clicks seem to be gone completely. Based on a few hours use, it is now as reliable as my old Macbook. This is a considerable improvement in the user experience for this laptop.
4 Likes
Now that it has been a few days, I can confirm quirks fix from linuxtouchpad.org does fix the problem for my FW13-AMD.
I have noticed that while typing, the cursor does sometimes move from the palm, but it does not tap! I’m not the original poster, but I would mark this as [SOLVED] for me.
2 Likes
I’m on Windows and my only solution has been to turn off tap to click, a feature I use regularly, but I can’t use the touchpad otherwise.
Can you share what the quirks file looks like?
I had been meaning to update this thread. Nothing had fixed the problem and I gave up on it. I disabled tap to click a month or two ago. I use the laptop while on my couch and realized my posture (and how that affected my hands’ position) was the main variable after all.
In any case, the quirks file is below, but I don’t think it helped.
/etc/libinput/local-overrides.quirks
[Serial Keyboards]
MatchUdevType=keyboard
MatchName=AT Translated Set 2 keyboard
AttrKeyboardIntegration=internal
[Touchpad]
MatchUdevType=touchpad
MatchName=PIXA3854:00 093A:0274 Touchpad
AttrKeyboardIntegration=internal
1 Like
Just spent some time pinning down a disable-while-typing issue. My problem turned out to be the keyd virtual keyboard. Most people report success from adding an AttrKeyboardIntegration=internal quirk (per linuxtouchpad.org link previously shared in this thread) but that was not the case for me. Querying libinput quirks list for the device confirmed that the quirks file had taken effect, but DWT issues persisted.
With keyd disabled, DWT is working as expected on my system. I assume I’d face the same issue with any other remap tool that surfaces as a libinput virtual device, but I haven’t actually tried. I’m able to replace keyd with xkb_options for my needs, so I’ll leave keyd disabled for now.
FWIW, I’m running Arch on an AMD FW13 with keyd@2.4.3-6, libinput@1.25.0-1, linux-lts@6.6.30-2, sway@1:1.9-3.
1 Like
Sorry, I’ve kind of “lost the thread” on this thread over the months as I struggle with this problem. I’m running Fedora 39 Silverblue/Bluefin/GNOME/Wayland. Before I go digging too deep on doing this with my weird distro, do you think this would be X-only (I’m guessing by “xkb,”) or are you using Wayland as well?
Yep, I’m using Sway, which is a Wayland compositor. (This is new territory for me, so take this with a dash of salt, but as I understand it Wayland still uses XKB formatting and libs for keymapping.)
I think the quickest way to test if our situations match is to run sudo libinput list-devices (you may need to install libinput-tools first) and see if keyd virtual device or keyd virtual keyboard is listed. If you see such a device in the listing then you probably installed keyd at some point for custom keyboard mapping.
If you’re using systemd then sudo systemctl stop keyd is a quick way to stop keyd temporarily. After that, try opening a text editor and see if palm rejection behaves any better. If it makes no difference then you can run sudo systemctl start keyd again and no harm done. It makes a big difference for me, so I used sudo systemctl disable keyd to keep keyd disabled permanently for now (but I’m leaving its installation and configs in place because I’m hoping there’s a fix out there rather than relying on xkb options as a limited workaround.)
2 Likes
Thanks. I’ve been using Fedora/Bluefin because of its awesome Framework-specific ISO, but there is no checkbox for DWT in the GNOME settings.
I just tried:
gsettings set org.gnome.desktop.peripherals.touchpad disable-while-typing true
and I think it’s helping so far. But sometimes it takes a day or two for me to determine if a change has been helpful or not.
Running sudo libinput list-devices doesn’t show anything with “keyd” or “virtual” so I think that’s a variation in our distros. But a part of the libinput list-devices output says Disable-w-typing: enabled. So I’m hoping that’s what I need.
If that gsettings fix is what I need, I will bring it up in the Bluefin forums; see if there’s a reason it isn’t in GNOME settings. I’ve been joyfully distro-hopping since I got this thing in November but this one issue isn’t well handled by any of them so far.
1 Like
I think I have narrowed down the problem some!
In Mac, when I start typing, the mouse pointer disappears as a sign that the touchpad is inactive while typing. Through all my experiments with different distros on the Framework, I don’t remember noticing the cursor ever disappearing.
When I entered the above “gsettings” command, I noticed the pointer disappearing like the Mac. Cool! Progress! In the last week, things are markedly better but I would still have palm clicks from time to time. Today. I was typing a long email in Chrome and the palm clicks were driving me crazy. And the pointer wasn’t disappearing.
From my testing:
The pointer does not disappear: Chrome, KeepassXC, Calibre, Pinta
The pointer disappears (and presumably disables while typing: Files, Double Commander, Text Editor, Software, Gedit, GIMP, Konsole, Ptyxis, Firefox
So it’s looking to me less like an unfixable hardware problem, but rather a bug at the application or toolkit level. Included GNOME apps work, and but does Konsole, so it doesn’t seem be a GTK/QT split. Going by the aesthetics of the nonworking apps, I’d guess it’s an issue of them using older versions of the toolkits.
I’ve been meaning to try migrating from Chrome to Firefox for awhile. I think this will make me do it.
2 Likes