[opensuse] Leap 15.2 erratic mouse shutdown/scrollwheel events
After upgrading from 15.1 [which ran kernel 5.8.0 from Kernel:stable] to 15.2 [running 5.8.1 from Kernel:stable], I notice a problem with the input layer: - When a number of mousewheel events have been issued through either touchpad or USB mouse, - applications such as firefox, inkscape, leafpad, - but, as far as I can determine, not xterm, xev, xfce4-terminal, or gtk3-demo, something, somewhere, dies, and - mouse events (click, scroll) get weirdly "buffered", - mouse movement on screen is possible, - but application receives no practical events, i.e. mouse cursor does not change when changing between plaintext and hyperlinks / buttons below mouse cursor no longer change color to a highlight Then, when, - a keyboard event occurs - any USB or HDMI cable is connected/disconnected, - analog audio cable is released/inserted (this sound chip has a Presence Detect feature, and so will do interrupts), all the buffered events get released/delivered. If it so happens the keybaord was used to "unstuck" the mouse and the key was Ctrl, I get the effect of e.g. Ctrl-MWheelDown in firefox, reducing the text size. - Changing USB autosuspend (/sys/**/autosuspend) to 0 has had no curing effect. Observation summary: - libinput has not changed - gtk3 problem? Xinput is fine, but so is half of the gtk3 apps. - I am probably going to venture into the kernel bisection, though I do not expect much between 5.8.0 and 5.8.1 This will make for a terrible one-package-at-a-time bisection :-/ Perchance somebody else noticed? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/17/20 7:10 PM, Jan Engelhardt wrote:
Perchance somebody else noticed?
I came across a potentially related issue having to do with keyboard input behaving similar. A soft-keypress not thinking a character had actually been entered following by a regular keypress that then output 2 of the same character, the first being delayed/buffered/etc.. I don't recall the list I was reading it from -- but the desktop there was KDE. May or may not be right on point, but this is the second delayed/buffered input problem I've run across in as many days. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday 2020-08-18 10:18, David C. Rankin wrote:
On 8/17/20 7:10 PM, Jan Engelhardt wrote:
Perchance somebody else noticed?
I came across a potentially related issue having to do with keyboard input behaving similar. A soft-keypress not thinking a character had actually been entered following by a regular keypress that then output 2 of the same character, the first being delayed/buffered/etc.. I don't recall the list I was reading it from -- but the desktop there was KDE.
Your case sounds like the Dead Keys keyboard layout feature of Windows and X11, where producing <é> is possible by utilizing the keys <'><e>, and a single <'> is producable by <'>< >. That is changable via the keyboard layout options of your desktop environment to a "nodeadkeys" layout. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday 2020-08-18 02:10, Jan Engelhardt wrote:
After upgrading from 15.1 [which ran kernel 5.8.0 from Kernel:stable] to 15.2 [running 5.8.1 from Kernel:stable], I notice a problem with the input layer:
- When a number of mousewheel events have been issued through either touchpad or USB mouse,
something, somewhere, dies, and
- mouse events (click, scroll) get weirdly "buffered", - mouse movement on screen is possible, - but application receives no practical events, i.e. mouse cursor does not change when changing between plaintext and hyperlinks
Narrowed it down to this single transition xfwm4-4.12.5-lp151.1.1.x86_64.rpm -> xfwm4-4.14.2-lp152.1.2.x86_64.rpm -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday 2020-08-18 12:29, Jan Engelhardt wrote:
On Tuesday 2020-08-18 02:10, Jan Engelhardt wrote:
After upgrading from 15.1 [which ran kernel 5.8.0 from Kernel:stable] to 15.2 [running 5.8.1 from Kernel:stable], I notice a problem with the input layer: - When a number of mousewheel events have been issued through either touchpad or USB mouse, something, somewhere, dies, and - mouse events (click, scroll) get weirdly "buffered",
Narrowed it down to this single transition xfwm4-4.12.5-lp151.1.1.x86_64.rpm -> xfwm4-4.14.2-lp152.1.2.x86_64.rpm
Reported to xfce4-dev list now. If anyone has a laptop whose touchpad appears multiple times in the output of the `xinput` command, please do speak up, I am curious if you are affected too. $ xinput ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ! ELAN0D01:00 04F3:3092 Touchpad id=16 [slave pointer (2)] ⎜ ↳ Dell Dell Wired Multimedia Keyboard Mouse id=11 [slave pointer (2)] ⎜ ↳ USB Optical Mouse id=13 [slave pointer (2)] ⎜ ! ETPS/2 Elantech Touchpad id=18 [slave pointer (2)] ⎜ ! ELAN0D01:00 04F3:3092 Mouse id=15 [slave pointer (2)] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
David C. Rankin -
Jan Engelhardt