No, I get it. I’m thinking of either cutting off most of my fingers or covering the track pad in wax paper. Either way, can’t lose, right?
I too wish there was some official setting. I just turned down the sensitivity to very low and it’s pretty much serving as my work around until an official setting is released, if ever.
It can be pretty bad. I’m always wondering what is happening with my typing before realizing that it must have been a lack of palm rejection.
1 Like
On any MS Windows laptop with a PrecisionTouchpad, if you are an administrator user and comfortable with regedit, then customizing PrecisionTouchpad registry settings for your hands might reduce palm clicks:
-
“Create a restore point” to backup the Windows Registry with the original settings, and then
-
In
regedit, try adjusting PrecisionTouchpad settings for your hands. Start by adding or increasing “Super Curtain” DWord value(s) for the edge(s) where your palm(s) cause clicks, and then restart MS Windows. Repeat until satisfied.
The settings are documented here:
I think the “himetric” unit is 1/100 of a millimeter, i.e., 10 microns, so 1cm would be 1000.
1 Like
I generally only boot into my Windows partition if I need to check out an ebook from my library and transfer it to my e-reader. (It requires a Windows-only Adobe app). I’m not at all knowledgeable about the Registry, so I don’t plan to attempt your suggestion. (Thanks though)
I have played around enough at this point to say the palm rejection problem is equally prevalent in Windows, Fedora GNOME, Ubuntu GNOME, Ubuntu Cinnamon, and Fedora KDE. I can’t tell that the KDE option to disable the touchpad while typing does anything.
This seems like a hardware issue but I admit that keeping the computer on my lap while reclining on a couch is worse compared to sitting at a desk.
On Linux, libinput might be relevant, particularly for touchpads by PixArt (not using a driver for touchpads by Synaptics).
libinput offers some local customization of matched touchpad device settings via /etc/libinput/local-overrides.quirks, including settings used for palm rejection like AttrPressureRange xor AttrTouchSizeRange.
A procedure to debug these settings for your touchpad and hands is documented here:
https://wayland.freedesktop.org/libinput/doc/latest/touchpad-pressure-debugging.html#debugging-touchpad-pressure-size-ranges
I appreciate the link, but I’m not sure it’s going to be helpful
matt@mattlappy ~/Downloads> sudo libinput measure touchpad-pressure
Using PIXA3854:00 093A:0274 Touchpad: /dev/input/event12
This device does not have the capabilities for pressure-based touch detection.
Details: Device does not have ABS_PRESSURE or ABS_MT_PRESSURE
matt@mattlappy ~/Downloads> sudo libinput measure touch-size
Using PIXA3854:00 093A:0274 Touchpad: /dev/input/event12
This device does not have the capabilities for size-based touch detection.
Details: Device does not have ABS_MT_TOUCH_MAJOR
This implies to me that palm rejection is not happening at all (which is what it feels like). It’s pretty disappointing. I’ve have to deal with a palm click about once per typed paragraph. It’s a definite step down from my 2017 Macbook Air.
FWIW, I tried out
sudo cat /dev/input/event19
Just to see what happens. It prints out the crazy text with even just a tiny touch from my palm. I have neuropathy and I’m pretty used to the fact that my fingers can touch my smartphone screen without feeling it. I apparently have less sensation in my palms than I thought.
That’s called pick and peck!
1 Like
Another reason why I prefer laptops with physical buttons for heavy typing. You just turn tap to click off completely and the problem is gone.
that’s alarming. is there any way to figure out if the device genuinely can’t do these things, or if it’s just a failure of the driver to access those capabilities?
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