Differences in axis values between compositors
Some compositors send an axis value of 10 (Mutter, Weston) per discrete step due to historical reasons and others send the scroll value from libinput (KWin, Sway), which is usually (or always?) 15. Partially because of this, many if not all clients completely ignore the axis value the compositor sends for axis_source=wheel
.
Now this is a problem mostly once a compositor wants to adjust the scroll speed - KWin has that functionality for example, and it works by simply multiplying the axis value by some factor specified by the user... but it doesn't really work that well. Some clients completely ignore the axis value for discrete scroll events (Qt, SDL), others apply it but have a much higher base scroll speed than on other compositors (GTK).
Now the question is: how can this be resolved? The options I see are:
- Mutter and Weston adopt the libinput scroll value, or KWin and Sway adopt the workaround of sending an axis value of 10 per discrete step. This isn't necessarily that great, as clients don't know if a compositor has adjusted to the 'correct' behavior
- specify one of the behaviors and add a version bump, so that clients can adopt accordingly
- add a completely new event without the historical baggage. As an idea, a
axis_pixels
event that specifies a scroll distance in pixels would provide both a fix for the inconsistency between compositors and help provide consistent scroll speeds between apps. I know that at least in Qt there is a matching API for that
Related: #87