Peter Hutterer

There’s one thing that’s bothering me about this “project”. How is it supposed to work with the upstream? Is this supposed to be a rivaling fork? How am I supposed to have it on my system?

Also, it rubs me the wrong way that the blog author is seeking a person to do all the dirty work — even for compensation — and then what? Have all the credit? Basically, act as a glorified Forward button?

If I felt up to the task enough, I’d slap a sponsorship button onto my github on my own. And here’s the difference: prior to asking for the money, I’d have something to show to prove I’m not a phony.

The upstream is not without its problem as well. Right now it’s being maintained by Peter Hutterer from Red Hat, and judging by his LinkedIn, it’s pretty much his job description. Recently he did a talk about how overloaded he is with libinput[1], and how someone volunteering to comb through pull requests and issues would easily become his “number two”. Which also is striking me as odd.

libinput, given its importance for Linux ecosystem as such in general, and Red Hat ecosystem in particular (especially since they bet on Wayland as the future, and there libinput is the only choice), is important enough that Red Hat better make sure it’s well maintained. It’s Red Hat/IBM, really, who should be interested in making sure the bus factor of libinput is > 1. Thus the problem should be raised within Red Hat’s management, and they should _hire_ additional people for fair buck to help. Otherwise…

I've never noticed such issue, quick search shows that one has to start on edge and movement in vertical direction [1]. Vanilla edges are 8% of the width on each side [2]. There was a proposal to add configuration option [3], rejected — they've tried this route before, it was impossible to test.

Fortunately source is there and it is easy to patch (try to set 0%). That's quite common, for example there are several patched libinput on AUR [5].

Does your hardware has firmware palm detection mechanism? Current bug [6] (Palm exclusion zones are not worth it on some hardware).

[1] https://wayland.freedesktop.org/libinput/doc/latest/palm-detection.html#palm-exclusion-zones

[2] https://gitlab.freedesktop.org/libinput/libinput/-/blob/f2baea50c01f9e10fb2076f5dd64311347ac5c3e/src/evdev-mt-touchpad.c#L3265

[3] https://gitlab.freedesktop.org/libinput/libinput/-/issues/190

[4] http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html

[5] https://aur.archlinux.org/packages/?O=0&K=libinput

[6] https://gitlab.freedesktop.org/libinput/libinput/-/issues/433

It's not really true at all. The libinput developer blogged about why having more configuration options has historically not actually been good for the project, or for users of the synaptics driver:

https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html

Particularly, once you add a configuration option, you're now on the hook to support that option indefinitely as long as the project exists and users expect that option to be there. With more maintainers and testers, it may become feasible to have more configuration options, but it's still not a good idea to just keep piling them in. It might be satisfying to see a big configuration panel with a lot of settings but it's a lot less satisfying when you figure out a lot of the configuration options don't work correctly because the underlying system has bugs or is under-maintained or was just never tested with your specific configuration because input is hard and requires near constant testing against an extremely large number of hardware devices.

Because it became a burden to maintain. https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html

> In the old synaptics driver, we added options whenever something new came up and we tried to make those options generic. This was a big mistake. The driver now has over 70 configuration options resulting in a test matrix with a googolplex of combinations. In other words, it's completely untestable. To make a device work users often have to find the right combination of options from somewhere, write out a root-owned config file and then hope this works. Why do we still think this is acceptable? Even worse: some options are very specific to hardware but still spread in user forum examples like an STD during spring break.

I was hoping for less "here's how your commit message should be formatted", and more "here's what your message should say". Though at least the blog it links to[1] discusses the latter.

No guidance on how many changes should make up one good commit (versus several)? No rules on referencing the issue tracker, or changes made by other contributors? No suggestions for when to put useful information (like "always do x when calling y()") in the commit or in a wiki or something?

[1] http://who-t.blogspot.com.au/2009/12/on-commit-messages.html

Me too! Following [1].

Maybe worth checking if one is not supported to use libinput instead of processing kernel events directly though. [2]

If someone is interested in the input topic, Peter Hutterer's blog is very nice to read. I also enjoyed his talk about libinput's bus factor [3].

[1] https://who-t.blogspot.com/2013/09/libevdev-handling-input-events.html

[2] https://who-t.blogspot.com/2018/07/why-its-not-good-idea-to-handle-evdev.html

[3] https://who-t.blogspot.com/2019/10/libinputs-bus-factor-is-1.html