Hutterer: Why libinput doesn't have a lot of config options [LWN.net]

Peter Hutterer writes about the cost of configuration options. "You see, whenever you write 'it's just 5 lines of code to make this an option', what I think is 'once the patch is reviewed and applied, I'll spend two days to write test cases and documentation. I'll need to handle any bug reports related to this, and I'm expected to make sure this option works indefinitely. Any addition of another feature may conflict with this option, so I need to make sure the right combination is possible and test cases are written.' So your work ends after writing a 5 line patch, my work as maintainer merely starts."

to post comments

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 7, 2016 16:58 UTC (Thu) by petur (guest, #73362) [Link] (1 responses)

"Legally, you have freedom to do almost anything with the software, so you can maintain a local fork of libinput with that extra feature applied. If that isn't acceptable, why would it be acceptable to merge the patch and expect others to shoulder the costs?"

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 7, 2016 19:16 UTC (Thu) by suy (guest, #81959) [Link]

It would be perfectly acceptable if the next patches arrived applying to my tree, instead of upstream, having to keep the burden of rebasing the change once in a while, forever. It's his project, so it's his choice to do it his way, we get that. But some people is not happy about it.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 7, 2016 20:22 UTC (Thu) by ledow (guest, #11753) [Link] (6 responses)

I consider options in an application I use the same as I consider constants when I'm programming myself.

Sure, I probably do want the X on the window to always appear in the top right corner. I can hard-code that. Or I can make it an option that it can go anywhere in the window title. Left, center and right is probably easy to do, doesn't take long to implement. Full "I'd like the minimise to be to the right of the close button" kind of window decoration? That takes longer to get right.

But hard-coding the option is fine at the start, but quite... prescriptive. My way or the highway. It's literally a line in "draw_window" that is placed where it needs to be and does the same thing every time.

Adding basic options, once you get past a certain point, isn't that bad. A series of constants, an option to chose one of three distinct definitions, individual cases programmed for each case, and maybe checks to make sure you haven't drawn it all over the same place.

Further options, sure, it gets complex at that point. Arrangement indices, alignment enums for each element, complicated interactions and impossible scenarios, etc. But a lot of flexibility. Your app probably wasn't a windowing library, so that's going too far.

I don't expect first versions of apps to have options. Literally, they are hard-coded prototypes. But once the programmer has programmed separate cases, broken off functionality to modular parts, and make a choice from some limited options, I don't see why that can't be offered to users. Command-line and config-file parsing, as soon as it's present in a program, doesn't take much to put in a few options for things that already exist.

But I don't expect full customisability for every possible option now matter how generic, obscure and weird a combination you can make. That's just silly and time-wasting.

However, it bugs me ENDLESSLY, when you have things like cdrecord that at one point would ONLY take SCSI numbering of devices, when previously and with third-party patches it still allowed specifying just raw devices names (/dev/sr0 or whatever) - that's just being petty for the developer to say "We don't do options".

I get that it's work. I get that it's boring. I get that if you started with SCSI names and only use SCSI names yourself as a developer that if the code's not there, it's a lot of work to put it in. But it's just petty to LEAVE OUT the way to change things that you had to make a decision on, which any one of a number of valid answers would "just work anyway", and which some users might well need, and for which the code to enable is pretty trivial. Mark it as experimental if you must. Because people are going to test and fix "experimental" options, but they aren't going to implement them from scratch for the same reasons as you didn't want to put in the option.

As much as developers are giving their time, without the users, they have a pet project that nobody downloads. Users are the testers, the writers, the debuggers, future developers. Nowhere near a significant percentage, but even one developer or keen helper is a significant bonus. And if providing things that already exist as "decisions" in the code makes them happy, I find it odd to refuse. Especially when it can just be as simple as "if(option_enabled(THIS_OPTION))" and a nice generic parameter library pulling in dozens of command-line, environment or config-file options.

I have to say, I used Opera for many years precisely BECAUSE of the customisability. I can literally turn it into whatever I like. I miss that. No modern browser offers that.

There's a reason that the kernel config has THOUSANDS of options, and that each distro chooses different options, and that most users never need to know until it affects them. I have recompiled a kernel just to turn on/off an option that was bugging me. Without the option to do so, I can't test, maybe I can't even progress, and I certainly can't debug where the problems are with it.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 7, 2016 21:13 UTC (Thu) by pebolle (guest, #35204) [Link] (2 responses)

> There's a reason that the kernel config has THOUSANDS of options, and that each distro chooses different options, and
> that most users never need to know until it affects them. I have recompiled a kernel just to turn on/off an option that was
> bugging me. Without the option to do so, I can't test, maybe I can't even progress, and I certainly can't debug where the
> problems are with it.

The kernel has, as of v4.6-rc2, probably over ten thousand separate configuration options. That's very impressive. It also comes at quite a cost.

For starters: it's madness to try to configure a kernel from scratch. The only sane thing to do seems to be to take a specific kernel's .config and tweak it a bit.

Another issue is that it's very hard to reason about the interaction of all these options. There's an entire group of people in the university of Erlangen, Germany working on a program that checks the Linux kernel basically continuously for the various mistakes people make when writing code that, somehow, depends on the interaction of these options. (Basically all the code depends on more than a trivial number of options.) Last time I checked there are still numerous issues in the tree.

Note that the person currently mentioned in MAINTAINERS for Kconfig is MIA. Michal Marek is doing much appreciated work, but I'm afraid it's telling Michal never bothered to formally take over Kconfig maintainership.

So, yes, kernel configuration is highly customizable. But, all in all, I'd guess that few people are happy about its current state of affairs.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 10, 2016 5:35 UTC (Sun) by flussence (guest, #85566) [Link]

>For starters: it's madness to try to configure a kernel from scratch. The only sane thing to do seems to be to take a specific kernel's .config and tweak it a bit.

From experience, it's *possible* to `make config` on a post-3.0 kernel, but that is an exercise in masochism (no backspace!)

I don't remember when I discovered "localyesconfig", but these days I can't imagine rolling a fresh kernel config without it. Big thank you to whoever added that, and nconfig too.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 12, 2016 20:27 UTC (Tue) by dlang (guest, #313) [Link]

I do a many kernel configuration fairly routinely. It's not nearly as bad as you make it sound because you normally have very large chunks of options that will very clearly never apply to you so you can turn them all off. For embedded systems, this turns into entire categories that are turned off.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 8, 2016 1:15 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

Libinput has a specific job to do and it's not user-facing software. The developer obviously wants it to remain a specific purpose non-user-facing piece of software. If nobody sees it or interacts with it then I expect it would please him to know that his software is doing it's job correctly.

I don't know if it's the best approach, but it's certainly a approach to software development that seems to work for him.

Everything has a cost associated with it. As software increases in capabilities it increases in complexity. Also software builds on the functionality provided by software before it. If every layer, every bit and piece of the OS desires some sort of attention in the way of user configuration and options then that creates a cascade effect of unintended consequences through every piece of software that has to interact with it.

It draws the attention of users and ends up distracting them from what the true purpose of a OS is... which is to run applications to get stuff done 'in the real world'. The more bits and pieces that attract attention and adds to the overall complexity is detracting from the end goal of the OS.

Like I said before, I don't know if it's the best or ideal choice for libinput to push dealing with hardware quirks or configuration options on other layers, but I don't think it's because he is ignorant and doesn't understand how to add configuration options or write configurable software.

It seems like a conscious and reasoned design choice.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 8, 2016 2:31 UTC (Fri) by whot (subscriber, #50317) [Link]

For clarification: the hardware-specific quirks can be broadly categorised into "device isn't doing what it's supposed to do" and "device needs special treatment".

We push the former category into udev because they're not libinput-specific and doing so makes the fixes available for other projects. Examples for this are the touchpad axis range fixes or the mouse DPI database.

The latter category includes things like "this touchpad cannot do two-finger scrolling, so don't enable it" and they remain private to libinput because scrolling itself is private to libinput. We only use the hwdb as a tagging system and we've been careful to not make this a configuration system, it's a device description system.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 8, 2016 14:10 UTC (Fri) by jani (subscriber, #74547) [Link]

> There's a reason that the kernel config has THOUSANDS of
> options, and that each distro chooses different options, and
> that most users never need to know until it affects them. I
> have recompiled a kernel just to turn on/off an option that was
> bugging me. Without the option to do so, I can't test, maybe I
> can't even progress, and I certainly can't debug where the
> problems are with it.

Yeah, the kernel has thousands of options, and the automated randconfig builds keep finding broken combinations. At build time. If it builds, it's good, right?

You're running pretty much untested configurations if you venture not too far off the beaten path (apart from enabling/disabling drivers). The config options give you a false sense of choice.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 7, 2016 23:18 UTC (Thu) by fandingo (guest, #67019) [Link] (5 responses)

Configuration options? That's old hat. It's all about user-controllable, embedded scripting engines and virtual machiens now! ;) Many games use Lua for player-controllable scripting and modding. The kernel has BPF (featured on LWN yesterday). Dynamic scripting within the JVM using jRuby, Groovy, etc. And, of course, the old king: Emacs. Just to name a few.

But, yeah, I totally empathize with Hutterer. Non-programmers have no appreciation that it takes anything more than an idea to create a feature and then reasonably support it. They also tend to overemphasize the importance of their personal use-case, thinking it's universal instead of a niche trifle.

(On a sidenote, I think it's hilarious when users whine about how software isn't configurable when it does include a scriptable VM. *cough* Gnome Shell *cough*.)

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 9, 2016 10:43 UTC (Sat) by Sesse (subscriber, #53779) [Link] (2 responses)

So if someone takes away behavior a large fraction of users want, it's not acceptable for them to complain, if they could theoretically implement it themselves in a script VM? Assuming said script isn't something like five lines, where's the big difference between that and “you can just modify the source”?

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 11, 2016 17:44 UTC (Mon) by fandingo (guest, #67019) [Link]

> So if someone takes away behavior a large fraction of users want, it's not acceptable for them to complain, if they could theoretically implement it themselves in a script VM?

If there's a hand that's feeding you for free, you're on thin ice by complaining at all. Obviously, we all complain to some degree, and that's fine. However, I think people need to keep in mind that the authors own you absolutely nothing, and you have no basis for demanding things.

> Assuming said script isn't something like five lines, where's the big difference between that and “you can just modify the source”?

Seriously? First, modifying the source is a huge pain. You need to get it, integrate it with whatever your distribution does (different version, distro patches, rebuilding package, etc.), build it, install it, and most importantly maintain it forever. Gee, I can't imagine what's unappealing about that. The benefit of scriptable extensions is numerous, but here's a few.

No compilation or limited to just the extension
marketplace for distribution
standard installation/execution process
sdk
can be sandboxed

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 12, 2016 17:41 UTC (Tue) by flussence (guest, #85566) [Link]

>Assuming said script isn't something like five lines, where's the big difference between that and “you can just modify the source”?

The obese elephant in the room, in most cases, is GNU autotools.

Could be worse, we could still be stuck with imake...

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 10, 2016 1:02 UTC (Sun) by cwillu (guest, #67268) [Link] (1 responses)

Upstream developers have no appreciation that it takes anything more than an idea to create a feature and then reasonably support it across various upstream versions. They also tend to overemphasize the importance of their preferred use-cases, thinking they're universal instead of a merely a large fraction.

Hutterer: Why libinput doesn't have a lot of config options

Posted Apr 17, 2016 20:45 UTC (Sun) by roblucid (guest, #48964) [Link]

touchee!! :)