Libinput 1.16 Will Warn You If Your System Is Too Slow

[phoronix]

Phoronix: Libinput 1.16 Will Warn You If Your System Is Too Slow

It's been over a half-year already for the current libinput 1.15 series for this input handling library used on both X.Org and Wayland environments. But libinput 1.16 is finally en route with the first release candidate out today...

http://www.phoronix.com/scan.php?page=news_item&px=Libinput-1.16-RC

[ssokolow]

If a system is so bogged down that input processing suffers, I'd think the more appropriate solution would be to automatically send a message to the compositor author telling them to either fix their damn compositor or, if it's not their fault, punt it up to the kernel devs to tell them to fix their damn scheduler.

Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.

[milkylainen]

Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.

You're absolutely right. But simple functions get lost in ever growing complexity.

[Min1123]

Where you normally see this is on server hardware, where it has a GPU that isn't capable of providing rendering (to a modern composited desktop), so software rendering is being used with full compositing effects. So ironically, computers with massive amounts of compute power (or just really bad GPUs) tend to be the ones that would encounter a warning, and they do so while the mouse is obviously taking a few seconds to refresh each time it's moved.

[royce]

If a system is so bogged down that input processing suffers, I'd think the more appropriate solution would be to automatically send a message to the compositor author telling them to either fix their damn compositor or, if it's not their fault, punt it up to the kernel devs to tell them to fix their damn scheduler.

Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.

The warning is probably to aid these people debug their kernel/compositor/whatever.

[discordian]

Where you normally see this is on server hardware, where it has a GPU that isn't capable of providing rendering (to a modern composited desktop), so software rendering is being used with full compositing effects. So ironically, computers with massive amounts of compute power (or just really bad GPUs) tend to be the ones that would encounter a warning, and they do so while the mouse is obviously taking a few seconds to refresh each time it's moved.

I bet I will see this on my Apollo Lake too.

[andreano]

In my experience, a laggy mouse pointer means you have about 1 second to free up some memory before the computer OOM-freezes. The OOM-killer might step in within an hour, or it never will.

[starshipeleven]

Where you normally see this is on server hardware, where it has a GPU that isn't capable of providing rendering (to a modern composited desktop), so software rendering is being used with full compositing effects. So ironically, computers with massive amounts of compute power (or just really bad GPUs) tend to be the ones that would encounter a warning, and they do so while the mouse is obviously taking a few seconds to refresh each time it's moved.

Mate, XFCE, LXDE/Qt, Enlightenment, and others don't have this problem, and should be a much better choice for a server or a device that has a crappy GPU to begin with

[starshipeleven]

In my experience, a laggy mouse pointer means you have about 1 second to free up some memory before the computer OOM-freezes. Either, the OOM-killer will do something within an hour, or it never will.

smash that "Alt+SysRq+f" button (not really)

On a more serious note, EarlyOOM works great to prevent freezing like that.

[tildearrow]

If a system is so bogged down that input processing suffers, I'd think the more appropriate solution would be to automatically send a message to the compositor author telling them to either fix their damn compositor or, if it's not their fault, punt it up to the kernel devs to tell them to fix their damn scheduler.

Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.

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

Or even better, GEOS on a C64 running at decimal 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.