Announcement

Collapse
No announcement yet.

Libinput 1.16 Will Warn You If Your System Is Too Slow

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

  • Libinput 1.16 Will Warn You If Your System Is Too Slow

    Phoronix: Libinput 1.16 Will Warn You If Your System Is Too Slow

    It's been over a half-year already for the current libinput 1.15 series for this input handling library used on both X.Org and Wayland environments. But libinput 1.16 is finally en route with the first release candidate out today...

    http://www.phoronix.com/scan.php?pag...binput-1.16-RC

  • #2
    If a system is so bogged down that input processing suffers, I'd think the more appropriate solution would be to automatically send a message to the compositor author telling them to either fix their damn compositor or, if it's not their fault, punt it up to the kernel devs to tell them to fix their damn scheduler.

    Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.

    Comment


    • #3
      Originally posted by ssokolow View Post
      Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.
      You're absolutely right. But simple functions get lost in ever growing complexity.

      Comment


      • #4
        Where you normally see this is on server hardware, where it has a GPU that isn't capable of providing rendering (to a modern composited desktop), so software rendering is being used with full compositing effects. So ironically, computers with massive amounts of compute power (or just really bad GPUs) tend to be the ones that would encounter a warning, and they do so while the mouse is obviously taking a few seconds to refresh each time it's moved.

        Comment


        • #5
          Originally posted by ssokolow View Post
          If a system is so bogged down that input processing suffers, I'd think the more appropriate solution would be to automatically send a message to the compositor author telling them to either fix their damn compositor or, if it's not their fault, punt it up to the kernel devs to tell them to fix their damn scheduler.

          Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.
          The warning is probably to aid these people debug their kernel/compositor/whatever.

          Comment


          • #6
            Originally posted by Min1123 View Post
            Where you normally see this is on server hardware, where it has a GPU that isn't capable of providing rendering (to a modern composited desktop), so software rendering is being used with full compositing effects. So ironically, computers with massive amounts of compute power (or just really bad GPUs) tend to be the ones that would encounter a warning, and they do so while the mouse is obviously taking a few seconds to refresh each time it's moved.
            I bet I will see this on my Apollo Lake too.

            Comment


            • #7
              In my experience, a laggy mouse pointer means you have about 1 second to free up some memory before the computer OOM-freezes. The OOM-killer might step in within an hour, or it never will.
              Last edited by andreano; 07-15-2020, 02:11 PM.

              Comment


              • #8
                Originally posted by Min1123 View Post
                Where you normally see this is on server hardware, where it has a GPU that isn't capable of providing rendering (to a modern composited desktop), so software rendering is being used with full compositing effects. So ironically, computers with massive amounts of compute power (or just really bad GPUs) tend to be the ones that would encounter a warning, and they do so while the mouse is obviously taking a few seconds to refresh each time it's moved.
                Mate, XFCE, LXDE/Qt, Enlightenment, and others don't have this problem, and should be a much better choice for a server or a device that has a crappy GPU to begin with

                Comment


                • #9
                  Originally posted by andreano View Post
                  In my experience, a laggy mouse pointer means you have about 1 second to free up some memory before the computer OOM-freezes. Either, the OOM-killer will do something within an hour, or it never will.
                  smash that "Alt+SysRq+f" button (not really)

                  On a more serious note, EarlyOOM works great to prevent freezing like that.

                  Comment


                  • #10
                    Originally posted by ssokolow View Post
                    If a system is so bogged down that input processing suffers, I'd think the more appropriate solution would be to automatically send a message to the compositor author telling them to either fix their damn compositor or, if it's not their fault, punt it up to the kernel devs to tell them to fix their damn scheduler.

                    Input processing isn't real-time video transcoding. If XFree86 could do it on a single-core machine clocked in double-digit MHz, then there's no excuse for it to starve for CPU cycles on a multi-core machine clocked in GHz.
                    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.
                    Last edited by tildearrow; 07-16-2020, 05:09 AM.

                    Comment

                    Working...
                    X