3 ms·

Woah, this solves the acceleration problem? I want to try it!! Thank you!

by toomim 5y ago

ComputerGuru 5y ago
You’re most welcome. Please read the article before downloading or cloning from GitHub: this “solves” the acceleration issue by not breaking it in the first place; imho what libinput should have done by developing gesture support on top of the existing, working driver/hardware stack instead of throwing away the userland/kernel separation and all layers of abstraction. The linked project is only the userland daemon that uses the raw Linux Multitouch Protocol events to interpret gestures; to get the acceleration curves working again I recommend using this in conjunction with xf86-input-synaptics as your actual input driver (which provides the correct acceleration curves for compatible hardware - basically all touchpads since they all cloned synaptics’ hardware once upon a time - but doesn’t by itself have gesture support). Side note: Syngesture (this project) isn’t dependent on X11 or Wayland, but I don’t know if anyone has ported or will port xf86-input-synaptics to Wayland, which is/was pretty much developed along the same lines as libinput: rewrite everything from scratch without taking into account that some things you’re throwing out actually work really well (regardless of the fact that they are built for X11 or not), get rid of all abstractions that made it possible to plug in better components/replacements at various points in the stack, and without a concern for actual feature parity for what they are purportedly replacing.
- shatteredgate 5y ago
  >rewrite everything from scratch without taking into account that some things you’re throwing out actually work really well This is not what happened. The synaptics driver and libinput were/are maintained by the same person, who has written about it extensively and explained why the approach in the synaptics driver does not work well. Specifically, some of the problems with the synaptics driver have directly led to decisions in libinput. You may want to read some of their blog posts if you haven't: https://who-t.blogspot.com/2016/12/xf86-input-synaptics-is-not-synaptics.html https://who-t.blogspot.com/2016/12/xf86-input-synaptics-is-n... https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-... https://who-t.blogspot.com/2016/03/why-libinput-does-not-have.html https://who-t.blogspot.com/2016/03/why-libinput-does-not-hav... It may seem like a good idea on its surface to have tons of abstractions and features and extension mechanisms, but that fades away when you get deal with the bug reports over a period of years and get to see all the problems it causes.

Woah, this solves the acceleration problem? I want to try it!! Thank you!

by toomim 5y ago

Woah, this solves the acceleration problem? I want to try it!! Thank you!

You’re most welcome. Please read the article before downloading or cloning from GitHub: this “solves” the acceleration issue by not breaking it in the first place; imho what libinput should have done by developing gesture support on top of the existing, working driver/hardware stack instead of throwing away the userland/kernel separation and all layers of abstraction. The linked project is only the userland daemon that uses the raw Linux Multitouch Protocol events to interpret gestures; to get the acceleration curves working again I recommend using this in conjunction with xf86-input-synaptics as your actual input driver (which provides the correct acceleration curves for compatible hardware - basically all touchpads since they all cloned synaptics’ hardware once upon a time - but doesn’t by itself have gesture support). Side note: Syngesture (this project) isn’t dependent on X11 or Wayland, but I don’t know if anyone has ported or will port xf86-input-synaptics to Wayland, which is/was pretty much developed along the same lines as libinput: rewrite everything from scratch without taking into account that some things you’re throwing out actually work really well (regardless of the fact that they are built for X11 or not), get rid of all abstractions that made it possible to plug in better components/replacements at various points in the stack, and without a concern for actual feature parity for what they are purportedly replacing.

shatteredgate 5y ago
>rewrite everything from scratch without taking into account that some things you’re throwing out actually work really well This is not what happened. The synaptics driver and libinput were/are maintained by the same person, who has written about it extensively and explained why the approach in the synaptics driver does not work well. Specifically, some of the problems with the synaptics driver have directly led to decisions in libinput. You may want to read some of their blog posts if you haven't: https://who-t.blogspot.com/2016/12/xf86-input-synaptics-is-not-synaptics.html https://who-t.blogspot.com/2016/12/xf86-input-synaptics-is-n... https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-... https://who-t.blogspot.com/2016/03/why-libinput-does-not-have.html https://who-t.blogspot.com/2016/03/why-libinput-does-not-hav... It may seem like a good idea on its surface to have tons of abstractions and features and extension mechanisms, but that fades away when you get deal with the bug reports over a period of years and get to see all the problems it causes.