> There's currently a gaping chasm between the 35 sponsors who have supported the project on GitHub so far (thank you!!!) and the 309 poll respondents who indicated they would donate to this cause.
Now I just realized that there is a github sponsor link, but it's recurring. I don't want recurring. I want to send $50 once.
follow the money. :)
I can afford a few bucks to help somebody to attempt to solve the problem. I'm even ok with failure as long as it's an honest attempt.
Not everyone has to be a developer - some of us may see better roles as funders, testers, project managers, etc.
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://liberapay.com/spbnick/donate 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.
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.
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.
They may want to care because not every device will be in the hw database at the outset. Or the existing description may be incomplete, and fail to account for something that libinput supports. Good hardware support starts from users "scratching their own itch" by experimenting with "advanced", less-strictly-supported options to reach the best combination for their hardware, and perhaps their niche use cases. Testability is a red herring because only a few advanced options will ever be applicable; the issue is that they're different options for different cases.
In libinput, people who understand the problem and are willing to work with the developers and contribute upstream can edit the hardware quirks. The maintainer has also blogged about this: https://who-t.blogspot.com/2018/06/libinput-and-its-device-q...
1) Giving drivers ways to expose additional functionality through extensions (a thin pass-through)
2) Giving abstract APIs which allow transformations between the input and the output
3) Having the mess live outside. The maintainer maintains interfaces, but not the exponential explosion of one-of-features and quirks.
Examples of such architectures include themable / programmable window managers (e.g. Enlightment/xmonad/etc.), Photoshop/gimp filters/extensions, or EMACS.
Whether or not this is a good idea is a different question. I don't have an opinion there. I definitely would have had time playing with something like this as a teenager. I just expect things to work as an adult with adult responsibilities. A lot of this comes down to target audience, resources available, and other questions which I have zero insight into.
If that were true, there wouldn't be crowds of people telling that palm rejection in Linux sucks balls. Seriously.
As someone who did dabble in libinput for my own needs, I probably qualify to tell you where exactly you can shove your $250 and your condescending ignorant attitude, and how deep you can shove it, too, along with the horse you rode in on.
> If that were true, there wouldn't be crowds of people telling that palm rejection in Linux sucks balls
Reading comprehension. Or intentionally selective misquoting. I'm not sure which one.
I said: "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)"
Point me to that, and I'll eat my words. My claim is that IF you provide all the plumbing and infrastructure, people will do the fun stuff. Plumbing isn't fun, though.
In either case, I don't think an inability to read "qualifies [you] to tell [me] where exactly [I] can shove [my] $250 and [my] condescending ignorant attitude, and how deep [I] can shove it, too, along with the horse [I] rode in on." It qualifies you for remedial third-grade reading classes. :) I highly recommend them.
I think I'm perfectly qualified to decide where to spend my own money, and it just went to DIGImend.
Reverse engineer the drivers and platform frameworks?
Edit: I'd gladly donate $2 or $3 per month.
Doesn't anyone own a table for eating where you can use your laptop as well?
I've been owning laptops for 12 years now and never used it on my lap. The only times I saw people use laptops on their laps is on TV.
If I wanted a computer I could only use at a desk with a mouse, I'd have bought a desktop.
You're right, though. I try to avoid doing that whenever possible.