I have the following Synaptics touchpad in my HP Envy (Gentoo Linux): [ 8.218270] psmouse serio1: synaptics: Touchpad model: 1, fw: 7.4, id: 0x1e0b1, caps: 0xd04773/0xe40000/0x5a0400 [ 8.308567] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input4 After the latest world emerge the synaptics touchpad (both xf86-input-synaptics-1.6.0 and 1.6.1) behaves in a strange way: When using the hardware left click button, the left click event reaches the application, allowing for single clicks. But when then trying to drag the mouse (as e.g. when selecting text or moving windows around the screen), the movement does not seem to be transmitted and the pointer does not move. It does change cursor shape, though (eg. when clicking on the window title bar in KDE and trying to move the mouse for moving the window, the cursor changes shape to the "four pointed arrow", the desktop effect desaturates the window content as it would when moving, but the mouse does not move) There is a description of the same bug some time ago in ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/736523 This is exactly the same behaviour. Up to the point that - double-tapping and then moving the mouse works - the left click button kind of works when pressing down only the very utmost edge (eg. with the tip of the fingernail, using 1 mm of surface) The problem occurs with xorg 1.11.4 and 1.12.1. No problem that seems related is reported in Xorg.log The problem does not occur with xf86-input-synaptics-1.5.2. After a downgrade to 1.5.2 the touchpad again works as expected.
Created attachment 62164 [details] xorg.conf with synaptics options I had to put all those options into xorg.conf because whithout them the touchpad was hardly useable at all: no right click, no tapping, jumpy behaviour etc.
(In reply to comment #1) > Created attachment 62164 [details] > xorg.conf with synaptics options > > I had to put all those options into xorg.conf because whithout them the > touchpad was hardly useable at all: no right click, no tapping, jumpy behaviour > etc. Actually, I remember a similar behaviour without the above options in xorg.conf: Left-clicking and then moving the mouse would produce a right-click event. This is why I had to put Option "AreaLeftEdge" "2000" Which made sure that the touchpad surface does not cover the left bottom mouse button.
can I have your Xorg.log and the evtest output of this device please. Ideally, you could also submit an evemu recording of the behaviour that reproduces the bug. http://people.freedesktop.org/~whot/evemu/
Created attachment 62281 [details] xorg.log with synaptics-1.6.1
Created attachment 62282 [details] xorg.log with synaptics-1.5.2
Created attachment 62283 [details] evtest output (1.6.1) capturing also a click-and-drag
(In reply to comment #3) > Ideally, you could also submit an evemu recording of the behaviour that > reproduces the bug. > > http://people.freedesktop.org/~whot/evemu/ Logs attached, unfortunately evemu does not install correctly on my platform: ./configure && make && make install ... /usr/bin/install -c -m 644 evemu/base.py evemu/const.py evemu/__init__.py evemu/exception.py '/usr/local/lib64/python2.7/site-packages/evemu' ../config-aux/py-compile: Missing argument to --destdir. ... # evemu-describe /dev/input/event5 evemu-describe: error while loading shared libraries: libutouch-evemu.so.1: cannot open shared object file: No such file or directory
Created attachment 62284 [details] evtest capture with 1.5.2
(In reply to comment #7) > Logs attached, unfortunately evemu does not install correctly on my platform: > > ./configure && make && make install > ... > /usr/bin/install -c -m 644 evemu/base.py evemu/const.py evemu/__init__.py > evemu/exception.py '/usr/local/lib64/python2.7/site-packages/evemu' > ../config-aux/py-compile: Missing argument to --destdir. > > ... > > # evemu-describe /dev/input/event5 > evemu-describe: error while loading shared libraries: libutouch-evemu.so.1: > cannot open shared object file: No such file or directory if install fails, than the library will be missing. You need to figure out how to fix this issue, I may need the recordings to reproduce. Not sure how you managed to get this error though. the python parts are optional though, so you can just run make install in the src directory and ignore the rest. you will also need to install into a prefix that is in your default library load path (usually ./configure --prefix=/usr) (In reply to comment #1) > Created attachment 62164 [details] > xorg.conf with synaptics options > > I had to put all those options into xorg.conf because whithout them the > touchpad was hardly useable at all: no right click, no tapping, jumpy behaviour > etc. can you remove these options please. most of them just set what is a default anyway and there may be some interference. in which case we need to figure out which option breaks it. Most of the patches in 1.6 are to enable useful behaviour on your clickpad _without_ needing any options.
(In reply to comment #9) > if install fails, than the library will be missing. You need to figure out how > to fix this issue, OK, just installing the binaries works: # evemu-describe /dev/input/event5 N: SynPS/2 Synaptics TouchPad I: 0011 0002 0007 01b1 P: 0d 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 01 00 00 00 00 00 B: 01 20 64 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 03 00 00 11 00 80 60 02 B: 04 00 00 00 00 00 00 00 00 B: 05 00 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 A: 00 1472 5672 8 0 A: 01 1408 4550 8 0 A: 18 0 255 0 0 A: 1c 0 15 0 0 A: 2f 0 1 0 0 A: 35 1472 5672 8 0 A: 36 1408 4550 8 0 A: 39 0 65535 0 0 > can you remove these options please. most of them just set what is a default > anyway and there may be some interference. in which case we need to figure out > which option breaks it. Most of the patches in 1.6 are to enable useful > behaviour on your clickpad _without_ needing any options. OK, I'll remove xorg.conf, install 1.6.1 and report back.
Hoorray! I've removed xorg.conf, installed 1.6.1. This left me with very basic touchpad functionality only, but the pad was indeed much more usable than before (1.5.2) without xorg.conf. To get all functionality I put this: synclient VertEdgeScroll=1 synclient HorizEdgeScroll=1 synclient TapButton1=1 synclient TapButton2=3 synclient TapButton3=2 synclient RTCornerButton=2 synclient RBCornerButton=3 synclient LTCornerButton=3 synclient LBCornerButton=1 Entering the same options in xorg.conf also works. The originally reported issue does not occur anymore. There still is some jumping around of windows when dragged with the left mousebutton pressed (but not after double-tapping on the title bar and then dragging them), but this is a perfectly minor issue. From my point of view, the issue was solved by removing some/one offending option(s) from xorg.conf. I'll try to enable them one by one via synclient and see if the issue reappears.
Unfortunately I could not determine a single option responsible for the behaviour. It seems to be related to TapAndDragGesture, which, when enabled, produces strange effects in the click-and-drag function. The effects are not consistent, though, and rather unpredictable. And the error was not reproducible by manipulating only this option. The bottom line seems to be: * TapAndDragGesture=0 -> Click-and-drag works in around 70% of all cases, Tap-and-drag does not work (the movement starts but stops after about 1/2 inch of movement) * TapAndDragGesture=1 -> Click-and-drag does not work at all (the behaviour originally described in this report, but the failure starts only ~60 seconds after enabling the option), Tap-and-drag works normally. But, as said above, only en/-disabling this one option did not produce the error. I had tested many other options before this one (i.e. changed them via synclient to the values given in my original xorg.conf), so it most likely is a combination of TapAndDragGesture with one or more other options. Given the multitude of possible combinations I have not tried to reproduce them manually. Is there a more structured approach via evtest/evemu?
(In reply to comment #12) > Is there a more structured approach via evtest/evemu? disable GrabEventDevice in the xorg.conf.d snippet and then run evemu-record. Try to reproduce the issue. Once done, you can use that sequence with evemu-play over and over again and it should always reproduce the issue until the magic option combination is disabled/enabled.
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it. Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.