Bug 1576351 - Mouse freeze and spurious key repetion since update to fc28
Summary: Mouse freeze and spurious key repetion since update to fc28
Alias: None
Product: Fedora
Classification: Fedora
Component: libinput
Version: 28
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-05-09 09:10 UTC by Erwan LE PENNEC
Modified: 2018-05-11 00:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-11 00:32:02 UTC
Type: Bug

Attachments (Terms of Use)

Description Erwan LE PENNEC 2018-05-09 09:10:08 UTC
Description of problem:
Since an update from fc27 to fc28, I'm suffering from some input issues:
- I observe some random short freeze of my mouse quite often
- Sometime so keys are repeated even if they was pressed only once

Version-Release number of selected component (if applicable):

How reproducible:
Each time I'm using my newly updated session.

Steps to Reproduce:
1. boot and log
2. play with the mouse and observe the pause (often)
3. type with the keyboard and obserse the repetition (less often)

I did not have those issues before upgrading my system.

Additional info:
HP Elite Book 840 G1

sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Sleep Button
/dev/input/event1:	Lid Switch
/dev/input/event2:	Power Button
/dev/input/event3:	AT Translated Set 2 keyboard
/dev/input/event4:	PS/2 Generic Mouse
/dev/input/event5:	SynPS/2 Synaptics TouchPad
/dev/input/event6:	Video Bus
/dev/input/event7:	Video Bus
/dev/input/event8:	HP Wireless hotkeys
/dev/input/event9:	HDA Intel PCH Mic
/dev/input/event10:	HDA Intel PCH Line
/dev/input/event11:	HDA Intel PCH Dock Line Out
/dev/input/event12:	HDA Intel PCH Headphone
/dev/input/event13:	HP WMI hotkeys
/dev/input/event14:	ST LIS3LV02DL Accelerometer
/dev/input/event15:	HP HD Webcam: HP HD Webcam

Comment 1 Erwan LE PENNEC 2018-05-09 09:13:19 UTC
The key repetition issue seems to appear more often when Ctrl is pressed.

Comment 2 Erwan LE PENNEC 2018-05-09 09:33:11 UTC
Last but not least, the issue seems to disappear when switching to Plasma.

Comment 3 Peter Hutterer 2018-05-09 09:47:10 UTC
Run sudo libinput debug-events in a terminal and reproduce the bug. Do you see the event stream stop when the cursor stops? If so, it's a libinput bug. Re-run with --verbose to see if anything interesting happens in that case, maybe there's a spurious palm detection happening or something like that.

Comment 4 Erwan LE PENNEC 2018-05-09 11:29:40 UTC
The event stream stops when the cursor stops and I see the following event:

event5  - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event5  - pressure: begin touch
event5  - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA

Comment 5 Jon Disnard 2018-05-09 21:30:01 UTC
I have the same problem statement. I'm on a Lenovo w541

The debug event stream does not show any indication of a button press when the mouse pointer becomes stuck. Note, this is using an external mouse and keyboard. So no chance of a stray key press while using the touchpad of the laptop (the lid is closed, on docking station). There is no event happening when the mouse pointer becomes stuck, and after the pause the events resume scrolling. 

Interestingly I decided to monitor /proc/interrupts in a tight loop while this was happening, and even those counters seem to pause. Here is what I was doing: 

while true ; do cat /proc/interrupts ; sleep 0.01 ; done

While monitoring the debug events, and observing the mouse pointer pause, I also would see all the counters stop, as if the bash while loop was momentarily suspended along with the mouse. But this could be a red herring, because I'm not exactly an expert with performance profiling. 

Also, I've tried down-grading libinput to each and every NVR since f28 branching, but recently went back to the most recent in bodhi. I thought maybe something happened recently, as the problem statement only happened after upgrading to F28 from f27. I also did a fresh install of f28 on another SSD laying around, and the same issues there. At this point I'm wondering if it's something in the kernel? I'm considering to downgrade to f27 kernels. That being said, I did try running in fluxbox under xorg and the issues seems to go away, so I'm not sure it's the kernel. Any troubleshooting suggestions are welcomed. Thanks!

Comment 6 Peter Hutterer 2018-05-10 01:32:28 UTC
Erwan: I'll need more context here because "event BUTTON_EVENT_UP" indicate that you've released a button here (but it didn't trigger a button event). Best to attach a short evemu-record sequence where you reproduced this bug.

The keyboard repeat events are most likely this one here:

You should try to switch to gnome on xorg and see if the problems occur there too, if not then it's gnome shell being too busy to process events. This also matches Jon's description.

Comment 7 Erwan LE PENNEC 2018-05-10 07:41:39 UTC
Switching to gnome on xorg seems to fix the issue, this is a suitable solution. I don't think you need the event stream anymore as this seems to be not related to libevent.

Thank you for your help.

Comment 8 Peter Hutterer 2018-05-11 00:32:02 UTC
Rightyo, closing this bug, it seems to be the gnome bug in comment 6 then. Please re-open if it re-occurs.

Note You need to log in before you can comment on or make changes to this bug.