xfwm: xinput2 change causes weird scroll event buffering
Jan Engelhardt
jengelh at inai.de
Tue Aug 18 15:36:29 CEST 2020
Greetings.
I have here a Fujitsu U728 laptop, which has the following xinput
pointy devices:
⎡ 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)]
Mouse handling has regressed for me since xfwm4 switched to xinput2 in
commit 6013f1ee9b3831991db6a0fb896f20537532b6ce.
After changing from 68b6854 to 6013f1, I notice a problem:
- When a number of scroll events have been issued through either
touchpad or USB mouse,
- applications such as firefox, inkscape, leafpad,
- but _not_ xterm, xev, xfce4-terminal(-0.8.9.2), or gtk3-demo,
something in xfwm "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 in
firefox / buttons below mouse cursor no longer change color from/to
their button highlight.
Then, when an interrupt happens, such as,
- a keyboard key is pressed
- any USB or DP/HDMI cable is (dis)connected
- analog audio cable is (dis)connected (there's support for Presence Detect),
the most recent 5-or-so events so buffered get delivered.
What I notice is that the U728 touchpad is represented as three
different xinput devices (15,16,18). For comparison, on a Lenovo X240
with a similar modern version of xfwm (that uses xinput2), there is
no issue observable, but the Lenovo touchpad is only present as one
xinput device. Not sure if that has anything to do with it...
More information about the Xfce4-dev
mailing list