Originally posted by skeevy420
View Post
Announcement
Collapse
No announcement yet.
Libinput 1.16 Released - Ready To Warn You If Your System Is Too Slow
Collapse
X
-
Originally posted by Hibbelharry View PostFeel free to try to use a browser from let's say year 2000 and surf any modern website. Hint: it won't work. Applications like browsers and a lot of other categories of desktop applications have all become much more ressource hungry while doing bigger and more complex jobs. Why o why don't people notice that user demand for functionality has risen quite a lot in the last 10 years?
On that same machine KDE 1 or 2 absolutely flys and is what I would call a bloatware desktop with a bazillion bells and whistles.Last edited by cb88; 03 August 2020, 12:56 PM.
Comment
-
Originally posted by jrch2k8 View Post
Because is Phoronix Forums and facts don't matter, only stuff like "i think, my opinion,etc." matter and most poster don't usually have the slightest clue of what the hell they are talking about or have done something completely sinful like actually read the code before let their mouth run off. aka The usual
- Likes 1
Comment
-
I just upgraded libinput in Debian Testing, and it tells me my system is too slow (Thinkpad, T540p, i5-4200M, 12GB):
Code:gnome-shell[1387]: libinput error: event7 - SynPS/2 Synaptics TouchPad: client bug: event processing lagging behind by 14ms, your system is too slow
Edit: I just checked the source code, apparently the threshold is 10ms. https://gitlab.freedesktop.org/libin...ommit/bd7b9106Last edited by franglais125; 03 August 2020, 05:17 PM.
Comment
-
Originally posted by 144Hz View PostDon’t like it? Then contribute.
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.
- Likes 4
Comment
-
Originally posted by DanL View Post..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 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.
- Likes 1
Comment
-
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.
Comment
-
Originally posted by skeevy420 View Post
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.
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).
Comment
Comment