Created attachment 1023483 [details] result for "xinput test 9" Description of problem: When using the ALPS touchpad of my E550 Lenovo, I encounter a weird problem. The bottom area of the touchpad -pretty much corresponding to where touchpad are often set up for horizontal scrolling) acts as a pointer deadzone. As soon as I enter it, the mouse pointer stops moving, reducing the usable area. Also, when dragging from down there up to the rest of the touchpad, a wheel button up signal is sent to X.org. Same with dragging from up where the touchpad woks alright, down to this dead pointer zone ends up in a button down signal being sent to X.org, which is extremely annoying, particularly when scrolling down (the touchpad is then pretty much useless). The touchpad works alright with gpm outside of X.org, and under the mandatory supplied with the laptop Windows 8.1. The problem only happens in X.org (even before logging in). Version-Release number of selected component (if applicable): - up to date Fedora 21 - last Fedora 22 beta live USB - fwiw, I encounter the same problem with Ubuntu 15.04 live USB How reproducible: systematic Steps to Reproduce: 1. launch "xinput test [touchpad id]" 2. drag down the bottom of touchpad 3. observe xinput seeing the movement of your finger, but with the pointer failing to move at all as long as it's down there Actual results: 4. observe the pointer starting to move again when getting far enough from the touchpad bottom 5. observe "button press 5" immediately followed by "button release 5" signal when entering this dead zone 6. observe "button press 4" immediately followed by "button release 4" signal when exiting this dead zone => see attached xinput-test file for "xinput test 9" command Expected results: - touchpad input makes pointer move, wherever you drag your finger - no 4th and 5th wheel buttons input Additional info: Also attach: - xinput-list-props file for "xinput -list-props 9" command - synclient file for "synclient" command
Created attachment 1023484 [details] result for "xinput -list-props 9" command
Created attachment 1023485 [details] result for "synclient" command
Also realized the pointer sometimes hangs all of sudden. I attached the log of an "xinfo -test 9": I moved the pointer very fast, until it ended up not moving at all, despite my finger continuing to move. Did several tryouts for this pointer hanging behaviour, and all of those reported the touchpad was tapped at x=0 coordinates when hanging... All in all, this touchpad is pretty much unusable, which is a shame. I had to get a laptop, as I'm bed ridden, convalescing from a thalamus stroke. I'll have to get an actual mouse, which is not gonna be even remotely practical in bed...
Created attachment 1024035 [details] output of "xinput -test 9" of the pointer (sometimes) hanging when the touchpad is at x=0
Oh! Just managed to fix the wheel buttons bug, tough through blind luck, and a dubious way. Tried out "synclient VertTwoFingerScroll=0", and I don't have anymore the weird out of nowhere wheel buttons signals when dragging from or to the bottom of the touchpad. Not a particularly acceptable solution, though... it just makes things look weirder and weirder...
Me again, with too much time on my hands. Hadn't noticed it earlier, but X.org logs show that, by default or with "auto-dev" protocol in xorg.conf, Synaptics fails to detect the proper protocol for this touchpad, which probably explains most of the problems. Though it's weird, as the logs tell me the synaptics module is unloaded right at launch, even though I get a few synaptics-eque functions (noticeably edge scrolling and multi-fingers tap). Tried to force it to "event", and bang: a nice old segfault... I attach logs for both cases down below...
Created attachment 1024059 [details] X.org logs showing failure to detect protocol by default/with auto-dev
Created attachment 1024060 [details] X.org logs showing segfault with forced use of even protocol
Hi, Thanks for the bug report. For Fedora-22 we are switching the input stack between the kernel and the Xorg xserver over to libinput, see: https://fedoraproject.org/wiki/Changes/LibinputForXorg So for starters lets switch your system over to libinput and see if things are better when using libinput. To do this, remove any custom xorg configuration files you've created and do: sudo dnf install xorg-x11-drv-libinput Then logout and log back in again, or reboot your machine. If things still do not work this way, then please: 1) Attach an xorg.log from xorg stared with xorg-x11-drv-libinput installed 2) Do "xinput list" and then "xinput list-props <id>" where <id> is the id for your touchpad as shown by the first command, and copy and paste the output of both commands to this bug. 3) And also generate an evemu recording of a problematic sequence of finger movements on the touchpad: sudo dnf install evemu sudo evemu-record The second command will show a list of input devices. Press ctrl+c to stop it, then do: sudo evemu-record /dev/input/event# > touchpad-problem1.log With # being the event node number for your touchpad. Then move your fingers over the touchpad in a way which causes one of the problems you are seeing and press ctrl+c. Now attach touchpad-problem1.log here together with a description of how exactly you moved your fingers, what happens in X when you move your fingers this way., and what you would have expected to happen. Lets starts with just one of the problems you are seeing and go from there. Regards, Hans
Hi Hans, Thanks a lot: I had completely forgotten about libinput. Pointer movements are much, much better, with it. It sure is a clear enhancement from synaptics (the touchpad is now quite usable), but there still are a few other problems: 1) activation of tap to click in a xorg.conf.d file (see libinput-50-touchpad.conf) doesn't work; this way, it shows as activated by "xinput -list-props 9" (see libinput-xinput-list-props-9.log), but fails to actually work; the weirdest is that an "xinput set-prop 9 272 1" actually makes tap to click (single, dual and triple fingers) work very well: so for now, I have set it up through a mere xinitrc.d script which serves as a good crutch (I have disabled this script execution for the logs I attach this time, fwiw) 2) only two fingers scrolling is available (edge scrolling is not even displayed as available through "xinput -list-props 9") 3) another problem with such two fingers scrolling: sometimes when I scroll with two fingers, when reaching towards the bottom of the touchpad, instead of stopping the scrolling (or continuing to scroll down, through I have not seen a way to enable coasting with libinput), the scrolling may then start happening back up, which is quite annoying (see libinput-evemu-wrong-scroll-bottom-touchpad.log) - it seems it happens if I then lift one of the two fingers before the other (it's obviously reproducible during a scroll down, the lower finger reaching the bottom of the pad, then when I lift the upper finger while leaving the lower finger on the touchpad; it also happens when one could say both fingers are lifted at the same time - so I guess in this last case, libinput is too sensitive, compared to my perception... ); weirdest is no such thing happens if I try it without the lower of the two fingers being near the bottom of the touchpad... 4) dead zones on the bottom and right part of the touchpad still somewhat exist: if I start a finger drag outside of those, I can thereafter reach the bottom or right side of the pad, with the pointer still properly responding, but if I start dragging from the bottom or right side of the touchpad, the pointer only starts moving when far enough from those sides (see libinput-evemu-deadzone-start-from-bottom.log) ; with the previous synaptics driver, as soon as the finger reached those areas, the pointer stopped moving altogether until I lifted the finger, then started dragging again, so it still is a huge enhancement (surely what makes the touchpad usable again the most) 5) the pointer still occasionally hangs, forcing me to lift my finger, and drag it anew for it to start moving again. I've noticed the surest way to replicate it was to drag my finger so the pointer moves erratically around some place on the screen, then suddenly moving the pointer in whichever direction, very fast, all without lifting my finger from the touchpad- it happens much less with libinpunt, though (see: libinput-evemu-sudden-pointer-freeze.log) I also attach the other logs you asked for: - libinput-xinput-list.log - libinput-Xorg.0.log If you'd rather I post those as separate bugs, just tell me. Also, I tested all that on Fedora 21: initially filled the bug for 22 as I was having the same exact problem under an SSD installed 21 as with a 22 live USB.
Created attachment 1024828 [details] xorg.conf.d config file trying to enable tap to click (unsuccessfully)
Created attachment 1024829 [details] result for "xinput -list-props 9" command using libinput
Created attachment 1024830 [details] result for "xinput list" command using libinput
Created attachment 1024831 [details] X.org logs using libinput
Created attachment 1024832 [details] output of "evemu-record /dev/input/event5" showing wrong scroll behaviour near the bottom of the touchpad Scrolled down with two fingers, moving those down to the bottom of the touchpad. Ended up with scrolling actually going down, but then up at the last moment. Scrolling should not have went up at all.
Created attachment 1024833 [details] output of "evemu-record /dev/input/event5" of a deadzone at the bottom of the touchpad Started draging my finger from the bottom of the touchpad. The pointer only started moving when far enough from that bottom of the touchpad. The pointer should have started moving at the same time as my finger did.
Created attachment 1024834 [details] output of "evemu-record /dev/input/event5" of the pointer suddenly hanging Started dragging my finger randomly around one area of the touchpad, then suddenly dragged it very fast in a clear direction, all in one move. Pointer then hanged, forcing me to lift my finger, then put it again on the touchpad, for the pointer to start anew responding to the moves of my finger. I should not have to lift my finger from, then lay it back on the touchpad, for the pointer to start following my finger oves again.
Hi, (In reply to noraef from comment #10) > Hi Hans, > > Thanks a lot: I had completely forgotten about libinput. Pointer movements > are much, much better, with it. It sure is a clear enhancement from > synaptics (the touchpad is now quite usable), but there still are a few > other problems: > > 1) activation of tap to click in a xorg.conf.d file (see > libinput-50-touchpad.conf) doesn't work; this way, it shows as activated by > "xinput -list-props 9" (see libinput-xinput-list-props-9.log), but fails to > actually work; the weirdest is that an "xinput set-prop 9 272 1" actually > makes tap to click (single, dual and triple fingers) work very well: so for > now, I have set it up through a mere xinitrc.d script which serves as a good > crutch (I have disabled this script execution for the logs I attach this > time, fwiw) That sounds like a bug in xorg-x11-drv-libinput, please file a separate bug for this, then Peter Hutterer, my college who knows much more about xorg-x11-drv-libinput, can take a look. > 2) only two fingers scrolling is available (edge scrolling is not even > displayed as available through "xinput -list-props 9") This is deliberate, you've a clickpad, and on clickpads people tend to rest their fingers at the bottom to do a left or right click, but the fingers are never 100% still so allowing edge scrolling leads to horizontal scroll events being send all the time by such a resting finger. I guess that if you never use the clickpad this way that you may still want to use edge scrolling. If that is the case please file a RFE bug against libinput for this, including some motivation why you believe we should revisit this decision. > 3) another problem with such two fingers scrolling: sometimes when I scroll > with two fingers, when reaching towards the bottom of the touchpad, instead > of stopping the scrolling (or continuing to scroll down, through I have not > seen a way to enable coasting with libinput), the scrolling may then start > happening back up, which is quite annoying (see > libinput-evemu-wrong-scroll-bottom-touchpad.log) - it seems it happens if I > then lift one of the two fingers before the other (it's obviously > reproducible during a scroll down, the lower finger reaching the bottom of > the pad, then when I lift the upper finger while leaving the lower finger on > the touchpad; it also happens when one could say both fingers are lifted at > the same time - so I guess in this last case, libinput is too sensitive, > compared to my perception... ); weirdest is no such thing happens if I try > it without the lower of the two fingers being near the bottom of the > touchpad... Looking at the evemu recording for this, this is a touchpad bug, the coordinates of one of the fingers jumps wildly at the end. This does seem something which I should be able to detect and ignore at the kernel level though. Can you please file a bug titled: "alps touchpad coordinate jumps at end of 2fg scrolling" against the kernel component and assign it to me at bug creation time. Please attach the same evemu recording there. Note if you forget to assign it to me at bug creation time just add me the Cc for the bug and I'll assign it myself. > 4) dead zones on the bottom and right part of the touchpad still somewhat > exist: if I start a finger drag outside of those, I can thereafter reach the > bottom or right side of the pad, with the pointer still properly responding, > but if I start dragging from the bottom or right side of the touchpad, the > pointer only starts moving when far enough from those sides (see > libinput-evemu-deadzone-start-from-bottom.log) ; with the previous synaptics > driver, as soon as the finger reached those areas, the pointer stopped > moving altogether until I lifted the finger, then started dragging again, so > it still is a huge enhancement (surely what makes the touchpad usable again > the most) This is by design (again) at the bottom of the touchpad we've a dead zone consisting of a left and right softbutton area for people who rest there left index finger there to do a click (like they are used to do with touchpads with physical buttons). We do not want those resting fingers to infuence pointer movement, so we ignore touches which _start_ in those areas unless they move out of the area. One solution is to just always start drags in the middle, which is what people do naturally / automatically anyways in my experience. Another solution if you do not use the left / right click at the bottom functionality is to switch the click finger method over to clickfinger. Then instead of using the right bottom area to right click, you can right click anywhere by clicking the pad with 2 fingers instead of 1. You can do this by setting the click-method to 0, 1 instead of 1, 0 in the xinput properties, then the dead zone at the bottom will go away. And with it also part of our argument for not allowing edge scrolling (the other part is that we really do not want config options to influence each other, so if we do allow edge-scrolling in this case we will simply allow it always which brings back the original problem). > 5) the pointer still occasionally hangs, forcing me to lift my finger, and > drag it anew for it to start moving again. I've noticed the surest way to > replicate it was to drag my finger so the pointer moves erratically around > some place on the screen, then suddenly moving the pointer in whichever > direction, very fast, all without lifting my finger from the touchpad- it > happens much less with libinpunt, though (see: > libinput-evemu-sudden-pointer-freeze.log) Looking at the evemu recording for this (thanks for those btw, very useful) in this case the touchpad simply stops sending data. There are 2 possible causes for this: 1) touchpad firmware bug 2) kernel bug. Please reproduce the problem and then do "dmesg" if you get messages in dmesg about ps/2 loosing sync we need to look further into this, otherwise I'm going to with explanation 1 and you're out of luck (you could try a bios update). Regards, Hans
Thanks again, Hans: 1) OK, will file a separate bug, and assign it to Peter Hutterer. Also, I realized as soon as I manage to enable it with "xinput set-prop 9 272 1" in my xinitrc.d script, I get a strange error code in X.org logs ("(EE) libinput: AlpsPS/2 ALPS DualPoint TouchPad: Failed to set ScrollButton to 0" - related to 4)?) 2) two fingers scroll is fine by me (though I don't use the clickpad functionality at all: much too imprecise, as it makes the finger moves slightly when you click, which makes the pointer move slightly; it may be fine when clicking on applications widgets and things like that, but is unusable to me for things like drawing in Inkscape, for instance) 3) OK, will file a separate bug right now, and assign it to you 4) Hmmm: don't see Click Method at all with "xinput -list-props 9" (see the previously attached libinput-xinput-list-props-9.log). Tried setting it with a line: Option "ClickMethod" "clickfinger" in xorg.conf.d, but it doesn't change a thing... 5) Damn... don't see anything in dmesg, even though I reproduced this hanging after a reboot (so to avoid filling logs too much- see libinput-dmesg.log). What's weird is it doesn't happen with the mandatorily supplied Windows 8.1 at all... BIOS is the latest available. Maybe they account for some weird implementation in the Windows driver...
Created attachment 1025055 [details] output of dmesg, failing to show a loss of PS/2 sync
(In reply to noraef from comment #19) > Thanks again, Hans: > > 4) Hmmm: don't see Click Method at all with "xinput -list-props 9" (see the > previously attached libinput-xinput-list-props-9.log). Tried setting it with > a line: > Option "ClickMethod" "clickfinger" > in xorg.conf.d, but it doesn't change a thing... Which version of xorg-x11-drv-libinput and libinput do you have / what does: rpm -q xorg-x11-drv-libinput libinput Say ? The latest available are 0.9.0: http://koji.fedoraproject.org/koji/buildinfo?buildID=630051 resp. 0.15: http://koji.fedoraproject.org/koji/buildinfo?buildID=635104 With those both installed you should get the click method. > 5) Damn... don't see anything in dmesg, even though I reproduced this > hanging after a reboot (so to avoid filling logs too much- see > libinput-dmesg.log). What's weird is it doesn't happen with the mandatorily > supplied Windows 8.1 at all... BIOS is the latest available. Maybe they > account for some weird implementation in the Windows driver... I'm afraid I see nothing which might explain this in the dmesg. Regards, Hans
4) Ha! I have: xorg-x11-drv-libinput-0.4.0-3.fc21.x86_64 libinput-0.7.0-3.20141211git58abea394.fc21.x86_64 So this clearly explains that lack. Will wait for the final release of F22 in around two weeks and will report back 5) Well, not such a biggie. It seems to happen much less with libinput than with synaptics, anyway, as said earlier.
judging by the comments above, I think this bug is fixed, with some extra bugs filed separately. Closing now, please re-open if it's still an issue. Thanks.