FWIW - though I rarely agree with the decisions in libinput on this matter or others, who-t deserves praise for the work, rigour and analysis done here.
That said, there’s some kind of “facepalm” to be had in that there’s more effort and real engineering being put into assuring a physical mapping between mouse samplerate/sensor resolution and physical travel than it is in other parts of the display stack (big topic, but it ties into mixed-DPI output and Waylands quite frankly retarded solution with using buffer scale factors).
My personal opinion / experience is that acceleration is the wrong solution for the problem - and there’s a draft in my article pile digging into ‘why’. The problem being that with big / multiple screens, the travel time (=effort providing the input) for moving the mouse cursor between different targets (windows), warrants breaking linearity for.
An alternative is what I added in durden for keyboard-dominant window management schemes, where the WM remembers position per window and ‘warps’ when your keyboard bindings change the selected window.
For stacking/floating, get an eye tracker(!) and let eye gaze region determine cursor start position (bias with a sobel filter and contrast within that region) and mouse motion set linear delta from that. Nobody has done that yet though ;-)
I seem to recall similar acceleration settings on other platforms (though, with a single slider for acceleration ratio). Has anybody done an analysis with similar curves for, ex., mouse acceleration on Windows?
in part 3, “I’ll probably also give the windows/OS X approaches a try (i.e. same curve, different constant deceleration) and see how that goes. If it works well, that may be a a solution because it’s easier to scale into a large range. Otherwise, shrug, someone will have to come with a better solution.”
FWIW - though I rarely agree with the decisions in libinput on this matter or others, who-t deserves praise for the work, rigour and analysis done here.
That said, there’s some kind of “facepalm” to be had in that there’s more effort and real engineering being put into assuring a physical mapping between mouse samplerate/sensor resolution and physical travel than it is in other parts of the display stack (big topic, but it ties into mixed-DPI output and Waylands quite frankly retarded solution with using buffer scale factors).
My personal opinion / experience is that acceleration is the wrong solution for the problem - and there’s a draft in my article pile digging into ‘why’. The problem being that with big / multiple screens, the travel time (=effort providing the input) for moving the mouse cursor between different targets (windows), warrants breaking linearity for.
An alternative is what I added in durden for keyboard-dominant window management schemes, where the WM remembers position per window and ‘warps’ when your keyboard bindings change the selected window.
For stacking/floating, get an eye tracker(!) and let eye gaze region determine cursor start position (bias with a sobel filter and contrast within that region) and mouse motion set linear delta from that. Nobody has done that yet though ;-)
I seem to recall similar acceleration settings on other platforms (though, with a single slider for acceleration ratio). Has anybody done an analysis with similar curves for, ex., mouse acceleration on Windows?
in part 3, “I’ll probably also give the windows/OS X approaches a try (i.e. same curve, different constant deceleration) and see how that goes. If it works well, that may be a a solution because it’s easier to scale into a large range. Otherwise, shrug, someone will have to come with a better solution.”
Ah, I missed that. Thanks!