Skip to content

wayland: Fix high-res scroll events with low-res clients

John Brooks requested to merge jbrooks/kwin:high-res-scroll-fix into master

These are the libinput events generated by a Logitech G604 on kernel 6.1.x when scrolling the wheel down one click:

 event3   POINTER_SCROLL_WHEEL    +2.467s       vert 7.50/60.0* horiz 0.00/0.0 (wheel)
 event3   POINTER_SCROLL_WHEEL    +2.476s       vert 1.88/15.0* horiz 0.00/0.0 (wheel)
 event3   POINTER_SCROLL_WHEEL    +2.480s       vert 1.88/15.0* horiz 0.00/0.0 (wheel)
 event3   POINTER_SCROLL_WHEEL    +2.485s       vert 1.88/15.0* horiz 0.00/0.0 (wheel)
 event3   POINTER_SCROLL_WHEEL    +2.489s       vert 1.88/15.0* horiz 0.00/0.0 (wheel)

The first number is the angle delta and the second number is the value120 delta. For every POINTER_SCROLL_WHEEL event, kwin would generate a wl_pointer::axis event. XWayland would turn each of these events into a button press/release pair. This was making scrolling much too fast on XWayland clients and any other client that treats axis events that way (such as QTabBar without this patch: qt/qt/qtbase!232 (fb4d94fb))

The wlroots behaviour is to only send an axis event to low-res clients once enough events have been accumulated to produce a wheel step. This patch makes kwin do the same.

There's a catch; this patch makes scroll speed ineffective for Qt applications due to the way Qt handles pointer frames. I'm still in the process of investigating all the different cases and the flow of events from evdev to kwin to clients and the best way to handle it. As far as 5.27 beta goes, I think scroll speed not working for Qt5 programs is a lesser bug than Xwayland receiving too many scrolls. Not caused by this patch.

Edited by John Brooks

Merge request reports