The article says that kernel 3.3 fixed the detection of ALPS touchpads (among others). I am running kernel 3.6.10 and my ALPS touchpad was not detected until I installed psmouse-alps-driver from the AUR. Therefore I suggest to rewrite the paragraph accordingly to say: "Some touchpads (e.g. ALPS, ...) need additional drivers to work. Install package X for touchpad Y." Any opposing arguments? Markus00000 (talk) 19:12, 15 December 2012 (UTC)
I have been experiencing an issue where the cursor sometimes starts jumping around the screen when trying to use it (as if its sensitivity is all over the place) I can not recreate it since it's pretty random when it happens so I can not test if the suugested fix at https://wiki.archlinux.org/index.php/Touchpad_Synaptics#Cursor_jump is for that or for another issue. In any case I have found a fix for it by doing 'sudo modprobe -r psmouse; sudo modprobe psmouse' to restart the mouse driver the thing is that I'm not sure whether I should add it to https://wiki.archlinux.org/index.php/Touchpad_Synaptics#Cursor_jump or make a new subheading under https://wiki.archlinux.org/index.php/Touchpad_Synaptics#Troubleshooting ?
- 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)
I was able to fix this issue by moving from evdev to libinput. See https://wiki.archlinux.org/index.php/Libinput. —This unsigned comment is by TapioT (talk) 09:09, 21 September 2016. Please sign your posts with ~~~~!
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.
In my example I started with
RightButtonAreaLeft = 3443 RightButtonAreaRight = 0 RightButtonAreaTop = 0 RightButtonAreaBottom = 3306 MiddleButtonAreaLeft = 2636 MiddleButtonAreaRight = 3443 MiddleButtonAreaTop = 0 MiddleButtonAreaBottom = 3306
$ synclient MiddleButtonAreaBottom=2450
X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 37 (X_ChangeDeviceProperty) Value in failed request: 0x129 Serial number of failed request: 22 Current serial number in output stream: 25
$ synclient RightButtonAreaLeft=3444
$ synclient MiddleButtonAreaBottom=2450 $ synclient RightButtonAreaBottom=2450
gave no more errors.
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
- It looks like that AUR package simply includes a similar patch to the one linked to in the warning. It is still a workaround since it simply removes the width-based palm detection.
- Silverhammermba (talk) 18:09, 4 February 2015 (UTC)
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.  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 Lahwaacz (talk) 14:11, 19 September 2015 (UTC) ? Depending on how much is (or will be in the future) the 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. --
- Sure, guilty of using Template:Tip to evade "strict" nomenclatura checks ;) No really:  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)
- 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  in installation and  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.
- Anything important missed? Close? --Indigo (talk) 20:13, 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.