Libinput 1.16 Released - Ready To Warn You If Your System Is Too Slow

[skeevy420]

Or just remove "your system is too slow" after all.
It is as bad as GitHub telling me "this is not the web page you are looking for" in a 404 error (even though often it is the page I was looking for).

Github does that a lot. Probably some bad caching heuristic in Google's search code.

I'd be down with removing it but I totally get why they'd want that error. I just think the error message should be clearer in what it's representing.

[tildearrow]

tildearrow CSD vs SSD has nothing to do with libinput. The Wayland Meritocracy ....

blegh... ignore, let pass, next page

[tildearrow]

DanL Thanks for sharing your feelings. Now let me share some facts. Peter Hutterer has done more than 95% of all commits and also maintains libinput. The second place contributor have done like 1% and is also a Red Hat dev. The project need more contributors if you want to cover more needs than just GNOME.

Why are KDE and Qt not contributing??

Sorry but what is the Wayland SSD protocol then? It was contributed by KDE.

If you say that it is of no value then you are a horrible troll.

[tildearrow]

I just want him to change the generic word "system" to the dynamic variable of "$COMPOSITOR" since that's what he says "system" means in the release notes, in that link in franglais125's post, etc.

Or, since sometimes it actually can be the system, include a database of not-good enough hardware to compare the current running hardware against and then use that for the system too slow warning combined with the above.

This isn't too different than master/slave and needing a change in terminology to make what is going on more clear and concise. In the current form it puts the blame on the system when the blame can be either the compositor (per its documentation) or the system (crappy hardware is crappy). At most I could open up an issue and see where that goes, but that's about it.

Or just remove "your system is too slow" after all.
It is as bad as GitHub telling me "this is not the web page you are looking for" in a 404 error (even though often it is the page I was looking for).

[RealNC]

a warning over "the system is too slow" will appear in the logs to inform the user

Users read logs?

[skeevy420]

skeevy420 Libinput is a simple lib with a small scope. It’s absurd to compare that with big scale kernel development.

The libinput maintainer currently targets GNOME. If you want more or better support, then you need to contribute.

I just want him to change the generic word "system" to the dynamic variable of "$COMPOSITOR" since that's what he says "system" means in the release notes, in that link in franglais125's post, etc.

Or, since sometimes it actually can be the system, include a database of not-good enough hardware to compare the current running hardware against and then use that for the system too slow warning combined with the above.

This isn't too different than master/slave and needing a change in terminology to make what is going on more clear and concise. In the current form it puts the blame on the system when the blame can be either the compositor (per its documentation) or the system (crappy hardware is crappy). At most I could open up an issue and see where that goes, but that's about it.

[Volta]

Wayland is not X11.

Thanks Gods!

[jrch2k8]

..or maybe the libinput maintainer (if it's just one person) could realize that there's more to the world than GNOME, that various desktops depend on the library, and that it would be helpful to test on multiple desktop to pinpoint the cause of issues.

I'm sure the developer don't have anything against other compositors but sometimes you have to focus you efforts and pick your battles and in this sense for a small team Gnome the most sense since it has the biggest amount of users (Ubuntu+RedHat).

I know in theory "Test Everything" sounds great but in practice is a huge time killer and not a very sound move if you are still implementing features with a small team, probably once the features slow down and API get more stable they will start going and optimizing/testing/automating other compositors.

[DanL]

Don’t like it? Then contribute.

LMAO. You complain about stuff all the time on this site (especially in non-GNOME desktops). But if it's something you like and someone else complains about it, suddenly it's ... "Oh, contribute blah blah blah.. patches welcome blah blah blah.. meritocracy.
In other words, you're not only a nasty troll, but a hypocritical one.

The libinput maintainer currently targets GNOME. If you want more or better support, then you need to contribute.

...or maybe the libinput maintainer (if it's just one person) could realize that there's more to the world than GNOME, that various desktops depend on the library, and that it would be helpful to test on multiple desktop to pinpoint the cause of issues. That's assuming what you say about targeting GNOME is true, which is not a good assumption given how much ridiculously biased bullshit you spew in any given week (or a busy day).

[franglais125]

I just upgraded libinput in Debian Testing, and it tells me my system is too slow (Thinkpad, T540p, i5-4200M, 12GB):

gnome-shell[1387]: libinput error: event7  - SynPS/2 Synaptics TouchPad: client bug: event processing lagging behind by 14ms, your system is too slow

This is on Gnome Wayland, 3.36. Isn't 14ms a bit high for input handling?

Edit: I just checked the source code, apparently the threshold is 10ms. https://gitlab.freedesktop.org/libin...ommit/bd7b9106