Libinput 1.16 Will Warn You If Your System Is Too Slow

[pal666]

However, still no way to set the pointer speed...

it's right in gnome settings

[bug77]

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

Not in Go, they don't
But yeah, usually they do.

[tildearrow]

i believe flat is no acceleration

flat is no acceleration ONLY if you set the factor to 0 (and you still cannot set mouse speed, like a multiplier)

[tildearrow]

it's right in gnome settings

yeah i know but it is so inaccurate, like, it does not even tell you the exact value (it's just a slider)

[Zan Lynx]

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.

In my opinion the problem is that display and user input is a real-time task and should be treated as such. Wayland compositors should be rearchitected to run all user input and all graphics updates in real-time threads with memlock'd RAM.

The real reason that the older Amiga, Mac and C64s were so responsive is that responding happened as a result of hardware interrupts and the response consisted of a few machine instructions. To update the mouse in C64 GEOS, for example, was an interrupt, and changing the sprite position. The actual drawing of the sprite was done in the video hardware.

It's not physically possible for modern computers to do the same thing because the GPU is not accessed with a few machine instructions. The input is not a simple interrupt anymore either.

But we could get a lot closer than we do by running code immediately in response to kernel events instead of waiting for thread scheduling in the middle of heavy computation threads, or waiting for memory paging. And we have all the tools available in the Linux kernel to do that.

Linux real-time is quite good. It isn't perfect, which means you wouldn't trust your anti-lock brakes to it, but it is nearly perfect. We should be using it for GUIs.

[ssokolow]

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

I never said anything about Wayland vs. X11.

I mentioned XFree86 because this is about libinput, libinput can also be plugged into Xorg, Xorg is the direct-line descendant of XFree86, and the precursors/deprecated competitors to libinput had no need to display "Your system may be too slow" messages on hardware 10 to 100 times slower during the XFree86 era.

Now, if you want to argue that's because they didn't use compositors back then, I might be convinced to debate the inferiority of Wayland for not having an option to do un-composited drawing for people who want the performance and reliability of uncomposited, tear-prone Xorg.

(Seriously. Even when it's the video drivers' fault, using a composited desktop reminds me of the bad old days of when I was on Windows and had to restart the system at least once a week.)

[pal666]

flat is no acceleration ONLY if you set the factor to 0 (and you still cannot set mouse speed, like a multiplier)

maybe(i have xset m 0). but i can set mouse speed right in gnome settings. ranging from crazy fast to crazy slow

[pal666]

I never said anything about Wayland vs. X11.

I mentioned XFree86 because this is about libinput

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

Now, if you want to argue that's because they didn't use compositors back then, I might be convinced to debate the inferiority of Wayland for not having an option to do un-composited drawing for people who want the performance and reliability of uncomposited, tear-prone Xorg.

i'm pretty sure compositors can run fullscreen windows uncomposited. 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

(Seriously. Even when it's the video drivers' fault, using a composited desktop reminds me of the bad old days of when I was on Windows and had to restart the system at least once a week.)

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

[yariv]

Wth, you mean to tell me after all these years, implementors still haven't learned you don't do stuff in the main thread/event loop? I find that hard to believe.

It's not that easy to split - even the Xorg threaded input took a while to implement. I think that there is some ongoing work regarding that in mutter, however since there is a lot of other ongoing work as well, that could take a while.

[bug77]

It's not that easy to split - even the Xorg threaded input took a while to implement. I think that there is some ongoing work regarding that in mutter, however since there is a lot of other ongoing work as well, that could take a while.

Nothing is "that easy" past "hello world" in the programming world. And yet I've learned to stay off the main thread in the first couple of months after I started dabbling with desktop GUIs. I find it hard to believe a bunch of better programmers than me would do such a thing.