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

[144Hz]

tildearrow CSD vs SSD has nothing to do with libinput. The Wayland Meritocracy already decided against SSD, so why do you want to discuss what is already dead?

KDE and Qt is not involved with libinput. Instead KDE users offer arm chair bikeshedding on forums. Why?

[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.

[144Hz]

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??

[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.