Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by skeevy420 View Post
    That's like when people say "read the source code". The Linux kernel has someodd 28 million lines of code. If you read each line for 3 seconds it would take around 2661 years of reading code to finish just the kernel. So the next time someone says "read the sources", remember that with the Linux kernel in 2020 kernel you would have had to start reading it sometime around 600BC just to do a quick, hasty, once-over glance reading of the kernel.
    Not to mention the fact that the kernel changes every day. Even small changes can have an effect, so you don't want to miss out on those.

    Comment


    • #12
      Originally posted by Hibbelharry View Post
      Feel 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?
      There is literally nothing on the web that I do that could not be done in 2005 (web store fronts, paying bills, forums, blogs, educational sites etc... )..... Opera 9.63 on a 2x80Mhz supersparc can actually browse the web in a usable if not speedy manner (minus modern SSL). Once you gut most webpages of the 100+ trackers, js and webasm blobs, you end up with hardly anything at all. There is some HTML5 stuff that ends up looking funky in old opera but Netsurf can usually render that and is just as speedy but not quite as usable since it lacks acutal JS support though there is some nascent support.

      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


      • #13
        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
        Then it will be time to change that perception and make Phoronix forum well backed informative challenging opinions so some posters can really think twice and hard.

        Comment


        • #14
          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
          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
          Last edited by franglais125; 03 August 2020, 05:17 PM.

          Comment


          • #15
            Originally posted by 144Hz View Post
            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).

            Comment


            • #16
              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'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.

              Comment


              • #17
                Originally posted by frank007

                Wayland is not X11.
                Thanks Gods!

                Comment


                • #18
                  Originally posted by 144Hz View Post
                  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.

                  Comment


                  • #19
                    Originally posted by phoronix View Post
                    a warning over "the system is too slow" will appear in the logs to inform the user
                    Users read logs?

                    Comment


                    • #20
                      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.
                      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).

                      Comment

                      Working...
                      X