4 ms·
Well, let me put it this way. I would donate $250 to fix it. I think that's how much working support for touch, trackpad, and pen input would be worth it to me.
by wegs 6y ago
Well, let me put it this way. I would donate $250 to fix it. I think that's how much working support for touch, trackpad, and pen input would be worth it to me.
I would donate $0 for a stranger on the internet to try to fix it themselves.
I would donate $0 and advise others not to donate with an approach where there isn't even a developer driving this themselves ("Give us money, and we'll hire someone to fix it" approach), especially with the claimed problem, solution, and approaches.
With open source, it's easy to find people to do the fun, modular bits (acceleration curves, palm rejection, etc.). It's hard to find people to do the plumbing and the not-fun bits. If OP were to create a pipeline which:
* Supported the broad range of trackpads, tablets, styluses, etc. on the market
* Did this with clean abstractions and modular drivers (NOT wrappers around wrappers around wrappers of what other people have written, but the painful work of refactoring other people's code)
* Integrated with the desktop properly, potentially extending existing standards if necessary (NOT tried to replace the desktop with yet another standard no one supports)
* Handled the odd-ball cases (a touchscreen, a drawing tablet, a drawing display, AND a plain old monitor are plugged into a box. What happens?)
* Provided clean, simple, documented, pluggable APIs where people could tinker around with the fun stuff (anyone can make a new algorithm in Python and see it work in 5 minutes)
That would solve the problem.
For reference, their approach: "(1) evaluate which multi-touch features can be implemented with the least work 2) start to quantify the current nature of palm detection 3) measure how the acceleration curve of Linux touchpad compares to that of macOS. I have some ideas on how we might calibrate the acceleration curve to better match macOS, but it would be handy if anyone else has bright ideas on how they would attempt to quantify the touchpad acceleration curve on macOS (such that we can seek to match it here)."
I could be wrong about all of this, but that's what it would take for ME to donate. I guess the other approach is to accomplish something yourself and establish a track record. I WILL instead donate to DIGImend, where a lone developer seems to heroically be successfully bringing tablet support to Linux. That's an example of a track record.
https://www.patreon.com/bePatron?c=930980 https://www.patreon.com/bePatron?c=930980
https://liberapay.com/spbnick/donate https://liberapay.com/spbnick/donate
https://www.buymeacoffee.com/spbnick https://www.buymeacoffee.com/spbnick
I'm sure this will go -5, since most critical posts do, but I find critical feedback to be more important than positivisty.
edit: Just donated to DIGImend.
- zozbot234 6y ago> If OP were to create a pipeline which: ... That would solve the problem. The libinput project and pipeline was developed as a way of pursuing these goals, but it doesn't even have all the features of the legacy synaptics driver. It's not hard to see where the work should be going: start with bringing libinput up to feature parity (and fork the project if maintainers won't accept your changes upstream), then go further from there.
- deleted 6y ago[deleted]
- cycloptic 6y agoForking libinput is unwise and would likely not be productive choice. The maintainer of libinput and the synaptics driver are the same person, and he has blogged several times about why the synaptics driver was a mess and was impossible to test and maintain. 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-...
- zozbot234 6y agoFirst of all, whether a "hardware database" is a better place for a device-specific option than a "config file" is just semantics; what actually matters is that supporting device-specific quirks should be straightforward for the end-user. As for user-facing options, if the maintainer thinks they are 'too expensive' to maintain in the code, that means the existing architecture of that code is misguided and should be refactored.
- cycloptic 6y agoIt was already refactored, into libinput. The issue with testability is not about the code being badly architected. The fact is if you have 100 config options and 1000 supported hardware devices, you must test all possible options and now your test matrix has something on the order of 2 ^ 100 * 1000 cases to go through. This combinatorial explosion is unsustainable. I personally disagree that device quirks should be straightforward for the end-user. The end-user shouldn't even care about this, the point is to make it so they don't have to mess with config files or a hardware database at all.