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):
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.
HP Elite Book 840 G1
No device specified, trying to scan all of /dev/input/event*
/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
The key repetition issue seems to appear more often when Ctrl is pressed.
Last but not least, the issue seems to disappear when switching to Plasma.
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.
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
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!
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.
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.
Rightyo, closing this bug, it seems to be the gnome bug in comment 6 then. Please re-open if it re-occurs.