Libinput 1.16 Will Warn You If Your System Is Too Slow

[NotMine999]

They could. But I actually meant sheer complexity.
In ever growing complexity, it's kinda hard to figure out what's going on sometimes.
Does not mean that code was badly written.

Like biological systems. We have a really tough time figuring out stuff, yet they were written by the masters. Evolution and time.
Does not mean that they are crappy designs.

Oh please. I cannot wrap my brain around your Twitterverse logic. And your lame man-splaining analogy is even worse.

To have the performance (or 'non-performant' in modern-day speak) issues of "libinput" mentioned in the article you would think is just shameful, embarrassing for a programmer, but I somehow doubt there is any shame or embarrassment to be had because "it's open source after all and if you can do better then fork it and do so".

Good programming used to be -->> Take 1 feature. Get it right. Take the next feature. Get it right. Resolve any conflicts between the two. Wash, Rinse, Repeat. And the project grows, albeit slower compared to today's standards, in a stable and reliable manner (unlike today's standards) even though bugs will appear (having bugs is actually a good thing). That development approach works in larger projects when project managers know HOW to implement it. Good project management seems to be a lost skill, and the people doing it now are "paper PM" types, "diploma mill PM" types filled with theories and ideas but totally lacking in practical knowledge.

Here we have "libinput": "libinput is a library to handle input devices in Wayland compositors and to provide a generic X.Org input driver" (from the Arch Wiki). X.Org worked before "libinput", so the function seems simple enough; we aren't talking LibreOffice suite complexity here, or are we? The project manager, or lacking that the lead programmer, of "libinput" should have the discipline to remain focused on the primary goal(s) of their code. Put that Steam game aside. Close Twitter and Facebook, and Slack, and whatever else. Focus on the coding. Get it right. Forget about competing projects, if they exist; drool & whine about them later, after the day's programming is done. Forget about "oohh ggee SHINY" new features that are usually nothing more than "whiz bangs" (simple but useless stuff). Get the code right, then get the code tight so it performs well; program function comes before program optimization, not in parallel since they sometimes conflict with each other.

Sadly this article suggests to me, as a retired manager, that these "libinput" programmers either:

1. Don't understand the task they are trying to solve; they might be better off programming something else.
2. Did not properly structure their approach to solving the problems of this project; tried to do too many things at once ("cart before the horse" problem).
3. Are not focused on the task they are trying to solve; distracted by outside stuff, making a buck, bug reports, feature wishlists, and so on.
4. Are not interested or do not know how to optimize & benchmark/test the performance of their code; code testing is easy to claim, but difficult to get right.
5. Or maybe they just believe and live by this: "it's open source after all and if you can do better then fork it and do so".

[ssokolow]

i mentioned x11 compositors because that's what is replaced by wayland

And I'm talking about xinput because that's what blames your system for being too slow. Wayland's only relevance is that only Xorg offers a choice between libinput and older alternatives.

i'm pretty sure compositors can run fullscreen windows uncomposited.

Yeah, real useful for someone who wants more than one window and is most concerned, in the context of Wayland, about compositor bugs either crashing their session or making it unusable. (With performance being assumed to be un-bad enough to be a secondary concern.)

if you want tear-prone xorg, you still have tear-prone xorg. wayland was specifically designed to improve upon that. well, you surely could do something tear-prone in compositor, but i doubt anybody will optimize for it

Mainly, my problem is that compositors generally go bad after a week or two of uptime. In the 20+ years I've been using Linux, I can count the number of times a driver bug took down un-composited Xorg before other concerns prompted a reboot one hand.

it's quality of implementation issue, nothing is wrong with wayland protocol. i'm sure both xorg and compositors had their share of bugs especially during growth

Xorg compositors never didn't have their share of bugs. That's why I run an X11 WM without compositing. Linux has yet to achieve a compositing setup capable of the uptime I demand. Hence my reference to the bad old Windows 98 SE days.

[milkylainen]

Oh please. I cannot wrap my brain around your Twitterverse logic. And your lame man-splaining analogy is even worse.

To have the performance (or 'non-performant' in modern-day speak) issues of "libinput" mentioned in the article you would think is just shameful, embarrassing for a programmer, but I somehow doubt there is any shame or embarrassment to be had because "it's open source after all and if you can do better then fork it and do so".

Good programming used to be -->> Take 1 feature. Get it right. Take the next feature. Get it right. Resolve any conflicts between the two. Wash, Rinse, Repeat. And the project grows, albeit slower compared to today's standards, in a stable and reliable manner (unlike today's standards) even though bugs will appear (having bugs is actually a good thing). That development approach works in larger projects when project managers know HOW to implement it. Good project management seems to be a lost skill, and the people doing it now are "paper PM" types, "diploma mill PM" types filled with theories and ideas but totally lacking in practical knowledge.

Here we have "libinput": "libinput is a library to handle input devices in Wayland compositors and to provide a generic X.Org input driver" (from the Arch Wiki). X.Org worked before "libinput", so the function seems simple enough; we aren't talking LibreOffice suite complexity here, or are we? The project manager, or lacking that the lead programmer, of "libinput" should have the discipline to remain focused on the primary goal(s) of their code. Put that Steam game aside. Close Twitter and Facebook, and Slack, and whatever else. Focus on the coding. Get it right. Forget about competing projects, if they exist; drool & whine about them later, after the day's programming is done. Forget about "oohh ggee SHINY" new features that are usually nothing more than "whiz bangs" (simple but useless stuff). Get the code right, then get the code tight so it performs well; program function comes before program optimization, not in parallel since they sometimes conflict with each other.

Sadly this article suggests to me, as a retired manager, that these "libinput" programmers either:

1. Don't understand the task they are trying to solve; they might be better off programming something else.
2. Did not properly structure their approach to solving the problems of this project; tried to do too many things at once ("cart before the horse" problem).
3. Are not focused on the task they are trying to solve; distracted by outside stuff, making a buck, bug reports, feature wishlists, and so on.
4. Are not interested or do not know how to optimize & benchmark/test the performance of their code; code testing is easy to claim, but difficult to get right.
5. Or maybe they just believe and live by this: "it's open source after all and if you can do better then fork it and do so".

Wow. Yes. You are indeed a "retired manager". Everybody else is stupid. Because you have project management skills?
I suggest your idea about the "libinput" programmers is total crap.
And it is open source. So YOU can fork it and do better. We are waiting.