Libinput 1.16 Will Warn You If Your System Is Too Slow

[bug77]

You mean that simple concepts get lost in heavily bloated poorly written code.

It's not possible to write complex, multithreaded code without the "simple concepts" getting lost, the sheer number of lines of code will take care of that. It's got a little better with the advent of async/await, but not all languages support that.

[ssokolow]

Or if AmigaOS could do it on a single-core machine clocked in single-digit MHz!

If they have to inform us that the system is too slow, then they are doing something too heavy in the input pipeline already.

That's a bit of an apples-to-oranges comparison. AmigaOS and Windows 3.1x had the relevant bits written in assembly as I remember and AmigaOS ran on different hardware with different applications, while XFree86 was written in C and is the direct-line ancestor of what these Wayland compositors seek to replace.

Heck, the UNIX Haters Handbook lambasted X for being such a temple to hubris and resource hog compared to highly optimized assembly things like Windows 3.1x.

[milkylainen]

You mean that simple concepts get lost in heavily bloated poorly written code.

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.

[YCbCr]

Pointer acceleration is pretty much mandatory, and there is no way to turn it off.
The acceleration profiles make no sense, like "Adaptive"? "Flat"?
Where is the "no acceleration" profile!!!

The "no acceleration" profile is called "Flat". It applies a constant acceleration factor regardless of the pointer velocity. Acceleration speed basically equals pointer speed with this profile.

"Adaptive" on the other hand uses a device dependent acceleration method taking the current pointer velocity into account.

[tildearrow]

The "no acceleration" profile is called "Flat". It applies a constant acceleration factor regardless of the pointer velocity. Acceleration speed basically equals pointer speed with this profile.

"Adaptive" on the other hand uses a device dependent acceleration method taking the current pointer velocity into account.

"Flat" does NOT mean "no acceleration". If it still applies acceleration, it is not "no acceleration".

No. Speed ≠ Acceleration. Look here.

In the graph:
- Red is what it should be with no acceleration (≈ Vx)
- Blue is what it is with acceleration (flat profile) (≈ Vx^1+a)

(where V = speed and a = acceleration)

Thankfully I found a way to disable mouse acceleration (by setting the acceleration factor to 0). However, still no way to set the pointer speed...

[pal666]

Input processing isn't real-time video transcoding.

but if they share same system, input processing has to wait

[pal666]

The acceleration profiles make no sense, like "Adaptive"? "Flat"?
Where is the "no acceleration" profile!!!

i believe flat is no acceleration

[pal666]

X11 compositors usually don't have this problem. That's because Xorg handles the input, and it does that in a separate thread.

xorg implementation details have zero relation to x11 compositors. on different server implementation they will behave differently

[pal666]

It's not possible to write complex, multithreaded code without the "simple concepts" getting lost, the sheer number of lines of code will take care of that. It's got a little better with the advent of async/await, but not all languages support that.

async/await have nothing to do with multithreading, coroutines run in same thread. they are syntactic sugar for callbacks

[pal666]

XFree86 was written in C and is the direct-line ancestor of what these Wayland compositors seek to replace.

wayland compositors replace x11 compositors in addition to server, and quite successfully