GNOME 42 To Finally Allow Input Events To Happen Full-Rate

[phoronix]

Phoronix: GNOME 42 To Finally Allow Input Events To Happen Full-Rate

An exciting new development for GNOME 42 is allowing input events to happen at their full input device rate, which is great news for high refresh rate Linux gamers, input tablets, and similar use-cases...

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-42-Input-Rate

[tildearrow]

Finally. Can't believe it took GNOME this long.

Now if only libinput devs would remove "your system is too slow" during delayed event processing in libinput...

[WebMac]

How is KDE Plasma handling this? Is it possible to use a mouse like the Razer Viper 8khz with 8.000 Hz on KDE?

[EvilHowl]

GNOME 42 is going to be the biggest update in years. Even bigger than GNOME 40.

[You-]

Finally. Can't believe it took GNOME this long.

Now if only Hutterer would change "your system is too slow" during delayed even processing in libinput...

I suspect patches are welcome. Or paid wages.

Otherwise namechecking a developer for features you want is not a good thing to do.

[tildearrow]

I suspect patches are welcome. Or paid wages.

Otherwise namechecking a developer for features you want is not a good thing to do.

And knowing how GNOME devs are, these patches wouldn't make it upstream without a lengthy argument, so there's no point on doing that.

Here is proof: https://gitlab.freedesktop.org/libin...t/-/issues/613

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.

[cl333r]

GNOME 42 is going to be the biggest update in years. Even bigger than GNOME 40.

You remind me of 144Hz, btw what happened to him?

[RahulSundaram]

And knowing how GNOME devs are, these patches wouldn't make it upstream without a lengthy argument, so there's no point on doing that.

libinput isn't specific to GNOME or even Xorg or Wayland. So that comment doesn't make much sense even if your assumptions are true.

[EvilHowl]

You remind me of 144Hz, btw what happened to him?

Well, I'm definitely not a troll and, unlike him, I don't really hate Qt and Plasma. I just enjoy GNOME more. But yeah, I haven't seen him in a while. He probably got banned or something.

[F.Ultra]

And knowing how GNOME devs are, these patches wouldn't make it upstream without a lengthy argument, so there's no point on doing that.

Here is proof: https://gitlab.freedesktop.org/libin...t/-/issues/613

How is that proof of anything when there is no patches to accept or decline in that gitlab issue? I'm also wondering what it is with that specific thread that you think is troublesome?