Description of problem: Fedora 22 use libinput to handle touchpad input for X, where one extolled benefit is palm detection to prevent accidental swipes and taps on the touchpad while typing. This doesn't work as if I touch the touchpad during typing it still throws off the mouse and can even "click" outside the edit area and cause various (some times data destroying) effects. Version-Release number of selected component (if applicable): 0.13.0-1.fc22 How reproducible: Always Steps to Reproduce: 1. select a text box on a web page, click in it then position the mouse outside the box 2. Type some text into the box 3. while typing touch the touchpad with your palm Actual results: The mouse pointer jerks and sometimes a click is performed if the touchpad detects a "tap". Expected results: The mouse pointer should not move and under no condition should the touchpad allow a tap while the keyboard is being used. Additional info: https://bugzilla.redhat.com/show_bug.cgi?id=1181565#c10 https://bugzilla.gnome.org/show_bug.cgi?id=747340
please run evemu-record against the touchpad device when you type to capture some of these erroneous events and attach the output here (keep it short pls, this is for palm analysis). also, what laptop model do you have?
I am having a very similar problem. My hardware is a Dell m3800. I am attaching a log. It seems to me that palm detection does work if I really rest my palms/thumbs on the pad. The problem shows up when the edges of my thumb or palm barely brush the pad. That must be close enough to a finger touch to fool it.
Created attachment 1013091 [details] evemu-record output from a Dell m3800 while typing
A suggestion based on what I suspect Apple OSX does: Ignore touch events near the top edge and sides of the touchpad until the user has started using it. Some timeout value since the last touch event perhaps. In my experience users begin using a pad near the center and not the edges, unless they are trying to trigger a Windows 8 edge event. Edge events were a horrible idea in my opinion and not something to be copied anyway.
Created attachment 1013198 [details] evemu-record output for AlpsPS/2 ALPS DualPoint TouchPad See attached evemu-record output. This is for the AlpsPS/2 ALPS DualPoint TouchPad device on a Dell E5440. The log includes 3 different event sequences: - up to 1.7s, typing while the right palm is grazing the right edge of the touchpad. - up to 5.9, typing while the left palm is grazing the left edge of the touchpad. - up to 12.3, typing while resting the palm on the center of the touchpad.
(In reply to Jonathan Briggs from comment #4) > A suggestion based on what I suspect Apple OSX does: Ignore touch events > near the top edge and sides of the touchpad until the user has started using > it. Some timeout value since the last touch event perhaps. we know when the user is typing, so we'll likely need to hook into that somehow. the timeout is sort-of what we had with syndaemon though I'm hoping we can do something slightly more adaptive. > In my experience users begin using a pad near the center and not the edges, > unless they are trying to trigger a Windows 8 edge event. Edge events were a > horrible idea in my opinion and not something to be copied anyway. fwiw, I used to think that, until I recorded my own interaction and looked at the touch points. Starting in the center is actually the exception, the finger is more likely to _end_ up in the center, i.e. if I want to move from left to some position I start left of the center and move the finger to the middle. That aside, your touchpad claims to be ~76 mm wide and we only activate it at 80mm. Try this scratch build here please, it should fix the left/right issue (not the palm resting one). http://koji.fedoraproject.org/koji/taskinfo?taskID=9474229
Jonathan: the evemu-record is cut off, so I can't tell if yours has the same issue. Without the top part of the file I can't emulate the device here.
Created attachment 1014526 [details] evemu-record of synaptic touchpad on Dell m3800 while typing This event log has all of the headers.
Oh that last evemu record was without the scratch build. I have not tried that yet.
Jonathan: the scratch build won't make a difference for you, the touchpad is ~100mm so the palm detection already enables. Replaying both of your event streams here show touches on the far outside edges, well within the palm detection zone. libinput ignores those. The last touch in the first recording you submitted looks like a normal finger movement, that one generates events and is likely the issue. If you watch yourself, you probably see that the only time palm detection doesn't work is when you touch somewhere towards the center of the touchpad. You can read up on the current palm detection here btw: http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html
In my second stream, I think that the edge of my thumb touched down on the pad and it caused a button event, causing my window to lose focus. I was testing by putting the pointer in another window so it was easy to tell when it happened. The event is E: 0.000000 0003 0035 5643 # EV_ABS / ABS_MT_POSITION_X 5643 E: 0.000000 0003 0036 2172 # EV_ABS / ABS_MT_POSITION_Y 2172 E: 0.000000 0003 003a 0041 # EV_ABS / ABS_MT_PRESSURE 41 E: 0.000000 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 0.000000 0003 0000 5643 # EV_ABS / ABS_X 5643 E: 0.000000 0003 0001 2172 # EV_ABS / ABS_Y 2172 E: 0.000000 0003 0018 0041 # EV_ABS / ABS_PRESSURE 41 E: 0.000000 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 That X position is all the way at the edge of the pad # Event type 3 (EV_ABS) # Event code 0 (ABS_X) # Value 5637 # Min 1386 # Max 5660 # Fuzz 0 # Flat 0 # Resolution 42 5643 is very close to 5660. The Y value is close to the center though, which matches up with where the edge of my thumb would touch. So I don't agree that this was a touch near the center of the pad. It was on the far right-hand edge near the center of the edge. I just tried it with xev and evemu-record appending into the same file and got this very similar one: E: 27.408357 0003 0039 1358 # EV_ABS / ABS_MT_TRACKING_ID 1358 E: 27.408357 0003 0035 5641 # EV_ABS / ABS_MT_POSITION_X 5641 E: 27.408357 0003 0036 1739 # EV_ABS / ABS_MT_POSITION_Y 1739 E: 27.408357 0003 003a 0034 # EV_ABS / ABS_MT_PRESSURE 34 E: 27.408357 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 27.408357 0003 0000 5641 # EV_ABS / ABS_X 5641 E: 27.408357 0003 0001 1739 # EV_ABS / ABS_Y 1739 E: 27.408357 0003 0018 0034 # EV_ABS / ABS_PRESSURE 34 E: 27.408357 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 27.408357 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 27.424902 0003 0036 1735 # EV_ABS / ABS_MT_POSITION_Y 1735 E: 27.424902 0003 003a 0032 # EV_ABS / ABS_MT_PRESSURE 32 E: 27.424902 0003 0001 1735 # EV_ABS / ABS_Y 1735 E: 27.424902 0003 0018 0032 # EV_ABS / ABS_PRESSURE 32 E: 27.424902 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 27.437036 0003 003a 0029 # EV_ABS / ABS_MT_PRESSURE 29 E: 27.437036 0003 0018 0029 # EV_ABS / ABS_PRESSURE 29 E: 27.437036 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 27.447058 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 27.447058 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 E: 27.447058 0003 0018 0000 # EV_ABS / ABS_PRESSURE 0 E: 27.447058 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 27.447058 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- FocusIn event, serial 36, synthetic NO, window 0x1c00001, mode NotifyNormal, detail NotifyNonlinear KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PropertyNotify event, serial 36, synthetic NO, window 0x1c00001, atom 0x12e (_NET_WM_STATE), time 58618886, state PropertyNewValue ButtonPress event, serial 36, synthetic NO, window 0x1c00001, root 0xee, subw 0x0, time 58618857, (89,91), root:(2039,220), state 0x0, button 1, same_screen YES
I was just poking though some of the libinput code and I don't see anything to exclude tap clicks through palm detection. I see the code to do it for motions. That does seem to be working fine. But nothing in there is checking the palm state when looking for clicks. This seems to match up with what it is doing. I can do up and down drags on the sides of the pad without moving the pointer. But if I tap the edges I can cause click events.
ah, I see. bug is already open for that one: https://bugs.freedesktop.org/show_bug.cgi?id=89625. We just haven't had time to fix it yet.
(In reply to Peter Hutterer from comment #6) > That aside, your touchpad claims to be ~76 mm wide and we only activate it > at 80mm. Try this scratch build here please, it should fix the left/right > issue (not the palm resting one). > http://koji.fedoraproject.org/koji/taskinfo?taskID=9474229 I've installed the scratch build, and it looks to have solved palm detection on the right side of the touchpad - if I rest my hand so that the palm is grazing the right side of the touchpad, I can move it quite a lot without the mouse cursor moving. It does causes taps from time to time, as noted in other comments. That being said - the situation with the left side of the touchpad is exactly the same - any movement around the left edge causes the mouse cursor to jerk around.
I'm not sure to understand where this discussion is supposed to lead, but I just one to point out that this bug makes Fedora 22 with GNOME 3.16 almost unusable on a (quite common) laptop with touchpad, from a productivity point of view (for doing usual stuff like writing emails, docs, spreadsheets, etc.). If it's not possible to resolve this bug completely (like having libinput behave like advertised or reverting back to some sort of GNOME 3.14 options to disable touchpad while typing), at least a solid workaround should be available to users.
ok, I had another look at your recording and I think the issue is that the left touches come very far into the touchpad zone, i.e. inside the current zone that we designate as palms. What I need from you, Oded, is to leave evemu-record running for quite a while so we can get an idea of whereabouts those touches happen. Pls use a mouse only while recording so the only events we get are palm events. Attach it to the bug here and I'll do the analysis
libinput-0.13.0-6.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.13.0-6.fc22
Created attachment 1015541 [details] More evemu logs Here is a longer recording, which - I estimate - includes several instances of incorrect palm detection. I believe I wasn't using the touchpad for actual mousing, as I prefer the keyboard integrated stick (which from evemu-record's output I understand is a different device). This isn't as much input as I would have liked, as I'm currently quite sick and not using the laptop as much as I normally do. I'll continue recording so let me know if you need more data.
hmm, touches are all over the place, hard to pick anything easy to hook onto out of this mess. Give this one a try please: http://koji.fedoraproject.org/koji/taskinfo?taskID=9516961 quick scratch-build with a disable-while-typing like timeout (500ms)
Sorry, not working for me - this basically does nothing, even less than the previous build. I think the main problem is with the tap prevention - as when I'm typing I don't care much if the mouse cursor move around, but if it causes a tap to be detected then it causes the text cursor to move and often select some text I've already written and my continual typing will cause data loss.
Sorry, my bad - the package didn't install correctly for me, hence I had the behavior that I reported the bug on :-( sorry... After installing the last scratch build, X crashes a few seconds after I log in, with this error in the log: [ 43707.327] (EE) [ 43707.327] (EE) Backtrace: [ 43707.329] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x599ce9] [ 43707.330] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7f811a92bb1f] [ 43707.330] (EE) 2: /lib64/libinput.so.10 (libinput_device_ref+0x14a) [0x7f81122900aa] [ 43707.330] (EE) 3: /lib64/libinput.so.10 (libinput_device_config_scroll_get_default_button+0x271e) [0x7f8112295d7e] [ 43707.330] (EE) 4: /lib64/libinput.so.10 (libinput_device_config_scroll_get_default_button+0xca7) [0x7f8112292957] [ 43707.330] (EE) 5: /lib64/libinput.so.10 (libinput_dispatch+0x5f) [0x7f81122900bf] [ 43707.331] (EE) 6: /usr/lib64/xorg/modules/input/libinput_drv.so (_init+0xa68) [0x7f81124a7e58] [ 43707.331] (EE) 7: /usr/libexec/Xorg (xf86Wakeup+0xe6) [0x479936] [ 43707.331] (EE) 8: /usr/libexec/Xorg (WakeupHandler+0x6d) [0x43ee0d] [ 43707.331] (EE) 9: /usr/libexec/Xorg (WaitForSomething+0x1e7) [0x592dc7] [ 43707.331] (EE) 10: /usr/libexec/Xorg (SendErrorToClient+0x111) [0x43a051] [ 43707.331] (EE) 11: /usr/libexec/Xorg (remove_fs_handlers+0x41b) [0x43e33b] [ 43707.331] (EE) 12: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f811a917790] [ 43707.332] (EE) 13: /usr/libexec/Xorg (_start+0x29) [0x428729] [ 43707.332] (EE) 14: ? (?+0x29) [0x29] [ 43707.332] (EE) [ 43707.332] (EE) Segmentation fault at address 0x0 [ 43707.332] (EE) Fatal server error: [ 43707.332] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 43707.332] (EE) [ 43707.332] (EE) Reverting to the libinput from Fedora 22 solves the problem.
libinput-0.13.0-6.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
weird, that looks like an unrelated bug that we fixed a few days ago (some devices having keys but not being set up correctly). Let's try again: http://koji.fedoraproject.org/koji/taskinfo?taskID=9544654
Created attachment 1019179 [details] Evemu record
I am also affected by this bug since upgrading to Fedora 22. No issues with trackpad under Fedora 21. Computer: Dell Latitude Z600 (circa 2008) Trackpad: AlpsPS/2 ALPS GlidePoint Libinput version is 0.14.1-2 I have attached an evemu-record session.
Andrew, did you try the scratch build from Comment #23? From the recordings, it looks like the only one there are two touches that matter here. One is at the top, roughly 15% down and 21% in. That one would probably be best served by a top area, similar to the one we have now. I filed an upstream bug here: https://bugs.freedesktop.org/show_bug.cgi?id=90189 Two movements look like finger movements here, so I'll ignore those. Two more touches could've been a palm, but they're hard to detect based on location, so a time-based solution like the one in comment #23 would work best here. Please give that build a try.
I installed the scratch build and rebooted. Gnome crashed, I believe when I did a tap to click. In a text console I removed the scratch package and ran dnf install libinput-0.14.1-2.fc22 to restore the original package and got the message that it was already installed. However after rebooting I now have the unhappy face message 'oh no, something has gone wrong'. There's a button with 'Log Out' option no way to select it (no response to space bar or tab). The usual Ctrl+Alt+FNx combo doesn't get me a text console either - did that feature get removed? I get the same screen after rebooting into rescue mode. Hope you have an idea cause my system is borked right now.
Never mind, booted from a Fedora USB image, ran dnf reinstall libinput, OK now. Whew.
fwiw, run dnf distro-sync <package> next time, that'll grab whatever package is currently in the distribution. if you just run install and you have a newer version installed (like the test package) it won't do anything.
ok, dangling pointer, that was a nasty one to find, but it's fixed now: http://koji.fedoraproject.org/koji/taskinfo?taskID=9583737
Peter, it's over a day since your last update but I'm not seeing a new version of libinput. Dnf is using the updates and updates testing repos and I'm running it with the --refresh option. My libinput version is still -0.14.1-2.fc2. Is there anything more I should do to see your change?
I'm running libinput-0.14.1-3.bz1209753.fc22.x86_64 , from the scratch build, and it works for me. It looks to use a standard "delay after typing before activating touchpad", which works for me so I can't complain :-), though a I was very much interested to hear about work to do *real* palm detection.
Andrew: all these so far are scratch builds, they're not submitted yet. Oded: yeah, it's the least preferable option. the timeout is a bit smarter (single key press has a smaller timeout than a long keypress) but I really hope I can somehow get away with something better than this. short-term this may be good enough though. The main problem is that on many touchpads palms and fingers look exactly the same, so unless we have some reliable heuristics (moves around on the edge, or at the top) I don't know what else to do. I'm all ears for good ideas though.
Peter, OK, took the plunge and installed the scratch build. No crash this time and better yet, palm detection is working well. Thanks very much.
Discarding moves that start from the edge or the top sounds like a good idea, but if I understand the problem correctly - different touchpads define different borders and sometimes what the user sees as the edge is not exactly what the software sees as the edge. Maybe some sort of tuning procedure to allow the user to help determine the edge at run time would be in order?
Andrew: thanks for testing, btw what are the physical dimensions of your touchpad? and what's your /sys/class/dmi/id/modalias? (In reply to Oded Arbel from comment #35) > Discarding moves that start from the edge or the top sounds like a good > idea, but if I understand the problem correctly - different touchpads define > different borders and sometimes what the user sees as the edge is not > exactly what the software sees as the edge. mostly true, though not the case anymore these days. non-synaptics touchpads give us the real edge. synaptics touchpads give us some value well inside the real edge, documented in the interface specs. exception here are the lenovo *40 and *50 series which give us the real edge. So we usually know what the edge is in device coordinates. Palm detection currently works as 5% of the left/right edge and this is what we should fine-tune, and/or switch to physical dimensions where possible I think. > Maybe some sort of tuning procedure to allow the user to help determine the > edge at run time would be in order? libevdev's touchpad-edge-detector does that but we only ever needed it for the lenovo *40 series (because the firmware was buggy). for most touchpad, you'll come up with what the firmware announces anyway. A separate problem here is that not all touchpads give us a resolution, so it's impossible to know how big the touchpad is physically.
My touchpad is 5cm high, 9cm wide /sys/class/dmi/id/modalias: dmi:bvnDellInc.:bvrA11:bd06/04/2013:svnDellInc.:pnLatitudeZ600:pvr:rvnDellInc.:rn0CY863:rvr:cvnDellInc.:ct8:cvr:
Maybe its possible to create a database of actual device sizes, like the smartctl guys are doing to handle the SMART attributes being reported differently on different devices? I think another problem is palm touch events that don't start with the palm sliding in from the edge - what happens when the user is hovering the palm over the touchpad while typing, and occasionally brushing the touchpad. Currently this causes the cursor to jerk quickly up and down and possibly generate taps. It looks to me like there could be a simple heuristic to detect that and silence the touch events for a second.
(In reply to Oded Arbel from comment #38) > Maybe its possible to create a database of actual device sizes, like the > smartctl guys are doing to handle the SMART attributes being reported > differently on different devices? yep, started that a short while ago :) http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-evdev.hwdb i mostly need to adjust the touchpad-edge-detector in libevdev to spit one of these out so it's easier to merge them. > I think another problem is palm touch events that don't start with the palm > sliding in from the edge - what happens when the user is hovering the palm > over the touchpad while typing, and occasionally brushing the touchpad. > Currently this causes the cursor to jerk quickly up and down and possibly > generate taps. It looks to me like there could be a simple heuristic to > detect that and silence the touch events for a second. without finger width (and touchpads don't give us that reliably) this isn't possible afaict. a small finger movement looks the same as a palm movement, so any heuristics usually fail on the false positive (worse than a false negative). Having said that, I'm definitely not claiming I had all ideas yet, if you can come up with something concrete (even in pseudocode form) I'm happy to review that and see how far we get with it. Having said that, that should probably be discussed in the upstream bugzilla then (bugs.freedesktop.org, Wayland/libinput).
libinput-0.15.0-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.15.0-2.fc22
I've pushed disable-while-typing in now but just as a heads up I'm not happy with it yet so it will change. Specifically the issue with a touch not being used as touch once the timeout expires looked better on paper than in everday use and will be fixed shortly. Meanwhile it should reduce the issues but to be on the safe side I gave it quite a high stable karma requirement.
Package libinput-0.15.0-2.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libinput-0.15.0-2.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-8457/libinput-0.15.0-2.fc22 then log in and leave karma (feedback).
can I get some testing on this scratch build here please, it aims to improve responsiveness of the palm detection, specifically allowing a finger to move the cursor once the timeout has expired (rather than requiring to lift it). Thanks. http://koji.fedoraproject.org/koji/taskinfo?taskID=9813926
I've installed the new version (0.15.0-2), but unlike some previous builds this one doesn't have "disable while typing" on by default. I understand that now its a feature that should be enabled somehow? I'm using Fedora 22 with GNOME Shell, and the GNOME touchpad configuration panel no longer has a checkbox for this feature. Is there another way to enable it?
Ok, with 0.15.0-3, disable while typing works out of the box. Also, if I have the finger moving on the touchpad, the mouse stops moving as soon as I start typing (and the cursor disappears) and resumes moving when I stop typing - without raising the finger. Though I'm not sure its a good idea - IMHO if we're trying to defeat palms resting on the touchpad, then if the user stops typing for a while you still wont to continue ignoring the touchpad until the user takes an affirmative action to perform gestures - i.e. changing position, disengaging from the touchpad and then performing the gesture.
There are three times a touch can start: before typing, after typing and during typing. Right now any touch that starts after the first and before the last key press will be ignored. So once you start typing if your palm rests on the touchpad the palm will be ignored indefinitely. If you start a touch after the last key press, then that touch is released. And likewise a touch that was interrupted by typing (tbh, not 100% sure how to deal with those yet, that one is a really complex problem). Also, what's the use-case for that, I honestly didn't think of that until now but I don't quite know when this would be common.
Ah, OK - that sounds reasonable. Regarding touch before, I can see this might be useful with someone using focus-follows-mouse, where they can use the touchpad to move the cursor over to another Window that requires keyboard input, type something and mine the cursor back - but I wouldn't know as I'm not using focus-follows-mouse :-)
libinput-0.15.0-3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.15.0-3.fc22
libinput-0.15.0-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.15.0-4.fc22
(In reply to Oded Arbel from comment #47) > Ah, OK - that sounds reasonable. > > Regarding touch before, I can see this might be useful with someone using > focus-follows-mouse, where they can use the touchpad to move the cursor over > to another Window that requires keyboard input, type something and mine the > cursor back - but I wouldn't know as I'm not using focus-follows-mouse :-) yeah, there are plenty of use-cases where basic heuristics break but in the end we have to deal with the data that touchpad give us (which is mostly insufficient to do anything smart). once the OEMs start building mind-readers into laptops we can start considering more complicated algorithms ;)
libinput-0.15.0-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.