Talk:Touchpad Synaptics

From ArchWiki
Jump to: navigation, search

ALPS touchpads

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)

Cursor jump

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)

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.

In my example I started with

   RightButtonAreaLeft     = 3443
   RightButtonAreaRight    = 0
   RightButtonAreaTop      = 0
   RightButtonAreaBottom   = 3306
   MiddleButtonAreaLeft    = 2636
   MiddleButtonAreaRight   = 3443
   MiddleButtonAreaTop     = 0
   MiddleButtonAreaBottom  = 3306

Trying

$ synclient MiddleButtonAreaBottom=2450

results

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

After

$ synclient RightButtonAreaLeft=3444

both

$ 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.

-- Peter0 (talk) 22:30, 22 June 2014 (UTC)

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.

Does this AUR:Package make it obsolete? Napterk (talk) 16:52, 4 February 2015 (UTC)

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)
Contribution of Gnufied split into new item #adding libinput alternative

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.
Anything important missed? Close? --Indigo (talk) 20:13, 24 September 2015 (UTC)
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.

—This unsigned comment is by Rallyemax (talk) 04:40, 10 October 2015‎. Please sign your posts with ~~~~!