Bug 102649

Created attachment 134150 [details]
Libinput device list

Created attachment 134176 [details]
Second debug event log

I've upgraded to libinput 1.8.2-1 from Debian unstable, but the issue still remains in place: I can see the mouse cursor moving if I'm typing with my palms resting on the touchpad. Attaching a second debug log. There are POINTER_MOTION events in it, which appear between two keypresses just 0.07 sec apart from each other.

Run libinput debug-events --verbose please and attach the output here, that should show if the touchpad is paired correctly for dwt.

Created attachment 134189 [details]
Verbose debug events

looks like the pairing between the two devices is correct, so that's not the issue. Do you have any configuration that may disable dwt?

The dwt code should ignore any touch that was started before the last key press, but we do ignore some key events (modifiers, mainly) for dwt to make things like ctrl+click possible.

Might be best to run libinput debug-events --verbose --enable-tap in a separate window and see if you can reproduce the tap there, when it happens attach the output here. This should give us some issue about the palm state of that touch. While doing so, also run evemu-record for the touchpad and the keyboard at the same time (note that this *will* record all keyboard events, so dont type passwords). attach the three files here and let's see if we can detect anything.

If you can't reproduce it with 10sec or so, please restart all three processes. Otherwise, the logs get too long to analyze or reproduce locally.

Created attachment 134211 [details]
Log groups 4 and 5

To answer your first question, I don't think I have any non-default configuration. I tried to use syndaemon to disable touchpad while typing, but that's only until I realized it doesn't work with libinput. And no, it's not the control key that I'm typing with. :)

I've recorded two sessions of events: the first one was myself typing the first sentence of this comment. This took longer than 10 seconds, but I certainly saw mouse cursor movement early on. The other one is just about 15 seconds, and has somewhat cleaner beginning hopefully, as I switched between terminal tabs using keyboard as opposed to the touchpad when starting it.

The first log recording started in the following sequence: debug-events, touchpad, keyboard. The second one was started as follows: debug-events, keyboard, touchpad.

Hope this helps. If it doesn't, I could try recording even more logs.

Created attachment 134212 [details]
Log groups 4 and 5

@Peter, did you have a chance to take a look at the logs?

This bug is so annoying that I ended up assigning a key to the toggle touchpad on/off function to work it around...

I don't know if you have a 4th gen or 5th gen X1 Carbon, but I experience exactly the same problem on my 4th gen, same libinput version. Guess I'll have to assign a key to toggle the touchpad off as well.

(In reply to Christopher Carr from comment #9)
> I don't know if you have a 4th gen or 5th gen X1 Carbon, but I experience
> exactly the same problem on my 4th gen, same libinput version. Guess I'll
> have to assign a key to toggle the touchpad off as well.

To clarify, I have libinput 1.8.2-1.

In addition to finding myself typing in an unintended location, on occasion I find myself overwriting inadvertently selected text. 

As you might imagine, this is especially problematic when writing code.

from libinput-debug-events5.log:
there's only one BTN_LEFT event, and that's towards the end. Everything else gets filtered. And the one in the end happens roughly 1s after the last key event and after a fair amount of movement.

from libinput-debug-events4.log:
that one is a bit weirder. There's an event at 56.59s and a pointer motion at 56.66. That one should have been filtered as palm though, it's within the timeouts. The palm detection works in other places though ('palm: palm detected (typing)') so this is some corner-case bug that I need to track down first.

Please try to reproduce it with git master though to avoid me having to waste time on debugging something potentially fixed already.

@Christopher: my Carbon is 3rd generation.
@Peter: i managed to compile a proper Debian package from the latest git, will see if anything changes. Assuming the library was reloaded right away, I see zero changes so far. As soon as I rest my palm on the touchpad, all kinds of unwanted stuff begin happening.

I pushed a patch to master today to make sure timeouts are flushed before any events are processed. I don't *think* that's the issue you're seeing but given the randomness of dwt not working on your box it could be influenced by it. Please give a6f0e4ae60177 or anything after that a try, thanks.

> Assuming the library was reloaded right away,

you'll have to restart X or the Wayland compositor, whichever applies. It won't reload otherwise (unless you're just using libinput-debug-events or something of course).

Ok, I have less of this issue now, but every now and again it resurfaces, which makes me think that perhaps I'm just touching the touchpad less, and the bug is still there.

I can't detect a difference.

I am hving exactly the same issue with a razer blade stealth 13.3 laptop. i wonder if the "disable while typing" may not work as expected. i checked the touchpad with the `xinput list-props` command

	libinput Disable While Typing Enabled (307):	1
	libinput Disable While Typing Enabled Default (308):	1

although it is enabled, i could still move the cursor and perform tap to click using the touchpad even if there is a keyboard key stay pressed.

linux kernel: linux-lts 4.9.52-1
libinput: 1.8.3-1

Kit: I think the razer blade issue may be related to the issue in bug 102039 (multiple keyboard devices but we only pair with one). That'd be a different bug than the X1 carbon which only has one internal device, please file that separately.

> from libinput-debug-events4.log:
> that one is a bit weirder. There's an event at 56.59s and a pointer motion
> at 56.66. That one should have been filtered as palm though, it's within
> the timeouts. The palm detection works in other places though ('palm:
> palm detected (typing)') so this is some corner-case bug that I need to
> track down first.

Ok, false alarm on this one. AFAICT this is simply an alt-tab which we don't activate dwt on (because alt is a modifier).

beyond that, I don't have anything useful yet. I really recommend that you guys grab libinput from git, increase the DEFAULT_KEYBOARD_ACTIVITY_TIMEOUT_1 and DEFAULT_KEYBOARD_ACTIVITY_TIMEOUT_2 and test with that. If that fixes it, we know that the issue is the timeout. Otherwise, we have some unrelated bug.

ping?

Is it OK if I just try with a 1.8.3 package?

1.8.3 doesn't have the timeout flush, so I'd rather you try with 1.9, otherwise we may end up wasting time debugging something that's already fixed.

Any updates here?

I just now updated to 1.9.1-1 on Arch. I'll restart X and see if I can provide some feedback.

FWIW, I did happen to glance at my hands recently exactly when I encountered the issue: I dropped my palms

I've compiled a Debian package of 1.9.1 and installed it today as well, will see how it goes and report back. Although I'm using my external keyboard a bit more at the moment.

(In reply to Christopher Carr from comment #23)
> I just now updated to 1.9.1-1 on Arch. I'll restart X and see if I can
> provide some feedback.
> 
> FWIW, I did happen to glance at my hands recently exactly when I encountered
> the issue: I dropped my palms

OK, I inadvertently submitted that comment because the issue occurred while I was typing.

It happens when lowering my palms while typing such that the meaty part of my left thumb muscle/palm lightly contacts the touchpad on the upper-left quadrant.

I'll restart now, test, and provide feedback soon.

It did not take long to determine that there is no improvement.

Same here, the cursor still jumps around as I type. Perhaps a bit less than initially, but it could be because I'm just holding my hands a bit differently or something like that.

(In reply to Peter Hutterer from comment #18)
> I really recommend that you
> guys grab libinput from git, increase the
> DEFAULT_KEYBOARD_ACTIVITY_TIMEOUT_1 and DEFAULT_KEYBOARD_ACTIVITY_TIMEOUT_2
> and test with that. If that fixes it, we know that the issue is the timeout.
> Otherwise, we have some unrelated bug.

I still need this ^^

Indeed, I completely forgot that. Could you suggest sane values for these?

The current timeouts are 200 and 500ms, respectively. So I guess anything longer than that? :) I would've thought 500 is plenty of time and anything north will seriously interfere with any touchpad usage. But I guess that's the point of testing this, at least to narrow down the exact issue.

Created attachment 135586 [details]
Debug event log with timeouts doubled.

I have doubled the timeouts to 400 and 1000 msec, but the issue still reappears when I type.

Attaching an event log, please check out lines near the end.

Note that when you run libinput debug-events it does *NOT* affect the running session. To test the new timeouts in the session you'll have to install and restart.

In the log in attachment 135586 [details] I can't see anything that could've caused interference. The pointer and keyboard events are separated, the only ase where there may be an issue is this one here:

-event2   POINTER_MOTION   +22.82s        0.00/  0.03
-event0   KEYBOARD_KEY     +22.85s      *** (-1) pressed
-event2   POINTER_MOTION   +22.86s        0.00/  0.11
-event0   KEYBOARD_KEY     +22.86s      *** (-1) released
-event2   POINTER_MOTION   +22.87s       -0.06/  0.12
-event0   KEYBOARD_KEY     +22.96s      *** (-1) released

but event2 is the trackpoint, not the touchpad so this cannot be dwt-releated. So either the extended timeouts worked or the log is incomplete?

Created attachment 135623 [details]
Another log

Adding one more debug log. Again, the cursor just jumped somewhere while typing.

If all this isn't helpful, please suggest what else I could do to help debug this.

are you running wayland or xorg? if the latter, do you actually use libinput? xinput list-props "device name" will tell you, check for the prefixes on the properties.

in the log above there are exactly zero motion events from the touchpad (except  the initial sequence before typing starts). there are a few events from the trackpoint (lines starting event2) but they're in the subpixel range and shouldn't cause the pointer to move significantly.

I'm running xorg and using libinput.

I'm not sure we follow each other. When you say there are no motion events, does that include taps or not? Because I can't really say that my mouse cursor moves, it's the text cursor that does. And it can surely move to where mouse cursor is even without moving the mouse cursor itself, a tap is enough.

I don't know if this qualifies as a tap or not though:

event1  - pressure: begin touch
event1  - thumb state: THUMB_STATE_MAYBE → THUMB_STATE_NO
event1  - palm: palm detected (typing)
event1  - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA
 event0   KEYBOARD_KEY     +19.58s      *** (-1) released
 event0   KEYBOARD_KEY     +19.58s      *** (-1) pressed
event1  - pressure: end touch
event1  - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE

running libinput debug-events has *no* effect on the current session, it's a completely separate context that just looks at the same events coming out of the kernel. assuming you use the same libinput version, what X receives should be the same as debug-events prints but otherwise they can be completely different versions - and have different configurations as well (see the libinput-debug-events man page for enabling the various options).

taps are printed as POINTER_BUTTON events. Annotated excerpt:


event1  - pressure: begin touch

detected a touch with high enough pressure that it counts as touch

event1  - thumb state: THUMB_STATE_MAYBE → THUMB_STATE_NO

ruled out as thumb

event1  - palm: palm detected (typing)

DWT is active, touch is labelled as palm

event1  - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA

touch is outside software button area

 event0   KEYBOARD_KEY     +19.58s      *** (-1) released
 event0   KEYBOARD_KEY     +19.58s      *** (-1) pressed

keyboard press + release posted - this is an event that will actually be passed on, so far we just had debug messages (note the one-space indent)

event1  - pressure: end touch

pressure dropped below threshold, touch is logically up

event1  - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE

touch is logically up for the software button code


That's it. note that the only events sent here were the two keyboard events, the rest is just debug messages. Note how there is no POINTER_BUTTON event in that log at all, just motion and keyboard events. I'm assuming you run with --enable-tap like requested above?

> I'm assuming you run with --enable-tap like requested above?

Of course not, I forgot. Will make a new one.

ping?

a month in needinfo, closing

Created attachment 136786 [details]
More logs.

Peter,
sorry for not respoding. The thing is, this problem isn't happening all the time, so reproducing it just for the sake of this logging requires a dedicated effort.

I just spent a good hour trying to set up logging of all three commands in such a way that all logs would start at the same time, and all loggers would be told to quit by a single ^C keystroke. I couldn't.

Thus attaching logs made in three different terminal instances which I then had to all kill separately. Thus they aren't aligned.

If this will be any helpful, I started `libinput debug-events` first, then the `evemu` keyboard logger, than the `evemu` touchpad logger. The cursor jumped between "t" and "ermina". In the keyboard logger log, this would be inbetween 13.722629 and 13.925078. Hope this will help.

At this point I'm almost inclined to start a campaign to raise funds to get Peter an X1 Carbon. This is a popular laptop among Linux users -- everything else works perfectly with it (excluding the fingerprint sensor). Touchpad functionality being unacceptable on a *Thinkpad* is most unfortunate.

@Peter, was there anything useful in my last logs?

"thee cursor jumped between "t" and "ermina"." - wait, I though we're talking about mouse taps detected?

Now that I'm reading the log again: the problem seems to be that your trackpoint sends random motion events. This is one case of movement while typing:
   event0   KEYBOARD_KEY     +15.72s      *** (-1) pressed
   event0   KEYBOARD_KEY     +15.78s      *** (-1) released
  -event14  POINTER_MOTION   +15.90s       -0.26/ -0.09
  -event0   KEYBOARD_KEY     +15.91s      *** (-1) pressed
   event0   KEYBOARD_KEY     +15.91s      *** (-1) pressed
  -event14  POINTER_MOTION   +15.91s       -0.73/ -0.29
  -event0   KEYBOARD_KEY     +15.98s      *** (-1) released
   event0   KEYBOARD_KEY     +15.98s      *** (-1) released

event14 is your trackpoint and it's not captured by the disable-while-typing because that's for touchpads only. So the question now is *why* is this thing sending the occasional movement? Are you touching it or just hammering on the keyboard hard enough?




As for starting multiple commands at the same time, screen is your friend:
$> cat test.screenrc
zombie kr
screen ls -lR
screen echo "hello"
$> screen -c test.screenrc

Will start 2 screens with ls and echo. Adjusting this example should give you almost exact timestamps in evemu and libinput debug-events.

(In reply to Peter Hutterer from comment #43)
> "thee cursor jumped between "t" and "ermina"." - wait, I though we're
> talking about mouse taps detected?
> 
> Now that I'm reading the log again: the problem seems to be that your
> trackpoint sends random motion events. This is one case of movement while
> typing:

<...>

> event14 is your trackpoint and it's not captured by the disable-while-typing
> because that's for touchpads only. So the question now is *why* is this
> thing sending the occasional movement? Are you touching it or just hammering
> on the keyboard hard enough?

I don't mind motion events. Whether I ram the keyboard, or accidentally manage to touch the trackpoint doesn't matter, as the trackpoint doesn't send click events.

I guess I should have been more explicit: "thee cursor jumped between "t" and "ermina"." referred to the text cursor, not mouse pointer. The point is, if I leave my mouse pointer above some place in the text and keep typing, eventually an accidental and unwelcome tap is sent, which moves the text cursor under the mouse cursor, thus messing up my text.

This interferes with me coding, as well as typing text (like this comment here – this has happened a few times already).

Hope this is cleared up now.


> As for starting multiple commands at the same time, screen is your friend:
> $> cat test.screenrc
> zombie kr
> screen ls -lR
> screen echo "hello"
> $> screen -c test.screenrc
> 
> Will start 2 screens with ls and echo. Adjusting this example should give
> you almost exact timestamps in evemu and libinput debug-events.

Thanks, I'll try this if necessary (that is if my previously attached logs aren't sufficient again).

Just to explain this once more:
"thee cursor jumped between "t" and "ermina"." means that while I was typing the word "terminal", text cursor was moved elsewhere after I typed letter "t", so "ermina" was inserted elsewhere in the text.

can you try libinput 1.10 please, it had palm detection during tap worked into the state machine properly. From what I can tell from this log your issue is likely to be:

event1  - pressure: begin touch 
event1  - thumb state: THUMB_STATE_MAYBE → THUMB_STATE_NO
event1  - palm: palm detected (typing)
event1  - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA                        
event1  - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH                                                
 event0   KEYBOARD_KEY     +16.68s      *** (-1) pressed
event1  - pressure: end touch   
event1  - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE                             
event1  - tap state: TAP_STATE_TOUCH → TAP_EVENT_RELEASE → TAP_STATE_TAPPED                                            
-event1   POINTER_BUTTON   +16.68s      BTN_LEFT (272) pressed, seat count: 1                                          
-event0   KEYBOARD_KEY     +16.75s      *** (-1) released
 event0   KEYBOARD_KEY     +16.85s      *** (-1) pressed
event1  - tap state: TAP_STATE_TAPPED → TAP_EVENT_TIMEOUT → TAP_STATE_IDLE                                             
-event1   POINTER_BUTTON   +16.73s      BTN_LEFT (272) released, seat count: 0        

so even though a dwt palm is detected, the tap state continues normal and that triggers a tap event. This should be fixed with libinput 1.10 though.

ping?

Sorry, I didn't notice your previous message in my inbox.
I shall try 1.10 and see how it goes, but I can't commit to a particular deadline with a response.

I shall try it as well, as soon as I'm able.

I'm now at 1.10.2. Will give it a spin for a couple days and let you know if I continue to encounter the same issues.  

Rimas' " ... cursor jumped between 't' and 'ermina' ..." description describes what I've been encountering exactly.

No complaints for 2 weeks, I'm assuming this got fixed then

Thanks Peter!

I'm probably still getting these symptoms every now and then, but their frequency has dropped to the level where it might actually be my slowness while typing as opposed to broken functionality. I believe this issue has been fixed.

Thanks again!

I suspect this was a complex problem, and the major component of it has been fixed. I'm definitely still running into the issue, but it's much less frequent. 

Whatever's still going on is going to be really hard to track down, I'm sure. I can't get it to happen when I try to (I easily could before) -- there must be something different about how I type when I'm purposely attempting to trigger the problem. But then it will still happen now and then when I go back to my regular work.

tbh, because dwt is timeout-based it's always a race condition waiting to happen. That's by design, simply because we don't really have any other data that we can work with. 

Making palm detection better and working it into the tap state machine improves things, but especially if you're triggering the timeouts or you have a device with pressure thresholds that don't apply, then it can happen more frequently.

fwiw, you can run libinput debug-events --enable-tap --verbose on the side and it won't affect your session at all. When it does happen you'll at least have some info that can hint of why the palm detection didn't work.

I have some marathon work sessions coming up soon -- will make sure to run that beforehand and see if I can get a log of the issue.

I'm not sure what has changed -- perhaps it's merely from changing the height of my chair -- but this is quite bad again. And unfortunately I've not been able to log occurrences. 

I did notice another complaint from a user with a newer 6th gen X1 Carbon (mine's a 4th gen device) -- so this is really an ongoing problem and is not substantially fixed.

I will continue to try to get a log.

Grab libinput git master, build it and run libinput record against your touchpad and the keyboard (it can record two devices at the same time). See:
https://wayland.freedesktop.org/libinput/doc/latest/tools.html#libinput-record

You don't actually have to install libinput from git to run the tool. This should show the race conditions (if any).

I've been using the built-in keyboard and touchpad of my ThinkPad exclusively for the past several months, and since upgrading libinput, I only occasionally, if ever, am having this issue of erroneous mouse taps being detected. I'm pretty certain that this problem has been fixed.

Peter, thank you once more!
Cheers.