Just saw your post about this questions in the forums, so it worked. I had the same problem and found a solution by running "syndaemon -d -K" at start up. Basically it disables the touchpad on the fly while you are typing, re-enabled automatically after you stop pressing keys. There are other options to vary the disable time, but I find the default works well. I can't remember where I found it, forum thread maybe? Anyway I'd vote for adding a list of things to try to the cursor_jump section of wiki. Keep the suggestion there now as list item 1, add yours as list item 2, and add the syndaemon as list item 3 one if you want Ajbibb (talk) 19:52, 21 October 2013 (UTC)

synclient

To my experience, synclient refuses to change i.e. the parameter RightButtonAreaBottom (by giving a BadValue error) as long as MiddleButtonAreaRight==RightButtonAreaLeft. Not before I adjusted MiddleButton and RightButton to be real adjacent – by increment RightButtonAreaLeft, synclient accepted changes to RightButtonAreaBottom and MiddleButtonAreaBottom.

As this is, in my opinion, a somewhat surprising behaviour, I'd add a note about this in the synclient-section.
Ok?

BTW: Setting RightButtonAreaLeft back to previous value 3443 wont give any error. Finally, trying to set it to 3442 yields a BadValue error. Seems there is a difference between overlapping and just touching.

Using the driver's automatic palm detection

Warning: For some touchpads, an issue with the kernel can cause the palm width to always be reported as 0. This breaks palm detection in a majority of cases. Pending an actual fix, you can patch the synaptics package to use only Z for palm detection.

adding libinput alternative

On my t450s installing xf86-input-libinput solves the problem of Palm detection not working with Synaptics driver. However using libinput also disables synclient so that is something to be kept in mind. I guess we should update palm detection section with libinput Gnufied (talk) 13:02, 2 August 2015 (UTC)

+1. I currently also marvel about the improvements I get for palm detection by simply switching to "Driver libinput" in the Xorg config. It seems a bit tricky task to integrate it as an alternative into the article, but imo a lot may benefit if it would be mentioned early on in Touchpad Synaptics#Installation and "Configuration" as an alternative for starters. --Indigo (talk) 19:51, 17 September 2015 (UTC)

Implemented that.[1][2] I'm unsure if it is useful to touch many of the subsections in Touchpad Synaptics#Troubleshooting for it too. Maybe a tip in a couple of the general ones (like palm detection or multitouch). Though, cleaner if libinput gets its own short article at some stage to avoid confusion with advanced configuration/troubleshooting for synaptics. It is all very hardware/driver dependant. --Indigo (talk) 13:54, 19 September 2015 (UTC)

Isn't "Touchpad Synaptics" related strictly to xf86-input-synaptics? Depending on how much is (or will be in the future) the xf86-input-libinput driver configurable compared to synaptics, it may be better to create a separate page for it. Or we can rethink the entire page (including its title), mention all alternative drivers directly in the "Installation" section and clearly separate the configuration sections for each driver. -- Lahwaacz (talk) 14:11, 19 September 2015 (UTC)

Sure, guilty of using Template:Tip to evade "strict" nomenclatura checks ;) No really: [3] is a good read. Once you look at slide20 I think it becomes clear that the libinput driver better get its own article right away. Not only because of being Wayland native but it will (does?) also support devices like touchscreens which Synaptics will never cover. With different device classes eventually come different tips&tricks, aside from the point that Options for both are not exchangeable anyway.

I vote for creating a Libinput expansion stub right away, using Xorg##Input devices#Touchpad to crosslink both and moving this article back to Synaptics once the stub contains basic setup instructions for the alternative. --Indigo (talk) 13:28, 20 September 2015 (UTC)

Sounds like a plan ;) There is also page on TrackPoint, which should serve as an intermediate between this page and the various laptop pages (mostly Lenovo), but I guess it will lose its sense if libinput fulfils its plans for the future. -- Lahwaacz (talk) 21:33, 20 September 2015 (UTC)

We'll see. Trackpoint appears to aggregate a lot of tweaks. Going to be interesting. evdev and libinput both do autoconfiguration of Lenovo trackpoints, so it should definetely be mentioned/linked there. I think for X mileage of each driver will vary for some time, depending on hardware capabilites, how they are supported by respective driver, desktop integration and what a user wants to customize. I'll setup an initial Libinput sometime soon then, unless someone is faster or another way to cover it arises in the meantime. --Indigo (talk) 23:13, 21 September 2015 (UTC)

Ok now we have libinput references [4] in installation and [5] in the palm detection subsection. Touched Trackpoint and Xorg to mention libinput. In my view that should suffice. I step back from the idea to move Touchpad Synaptics for now; not enough gain for a truckload of broken backlinks.

There are still many pages using the Synaptics redirect instead of full Touchpad Synaptics, so I think that renaming this page would still be beneficial. -- Lahwaacz (talk) 20:27, 24 September 2015 (UTC)

Outdated "Touchpad synchronization issues" section

The section is rather hopelessly out of date. First, it refers to the pre-systemd /var/log/messages.log.

Second, it refers to CPU scaling methods that do not apply to most modern Intel chips -- on most modern chips, pstate controls scaling and there are no more traditional scaling governors such as ondemand. Certainly some users (including myself, on my headless server) still have older chips and chipsets, and thus utilize non-pstate frequency scaling, but I imagine that for the majority of users, that is arcane stuff nowadays.