Announcement

Collapse
No announcement yet.

GNOME 42 To Finally Allow Input Events To Happen Full-Rate

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

  • GNOME 42 To Finally Allow Input Events To Happen Full-Rate

    Phoronix: GNOME 42 To Finally Allow Input Events To Happen Full-Rate

    An exciting new development for GNOME 42 is allowing input events to happen at their full input device rate, which is great news for high refresh rate Linux gamers, input tablets, and similar use-cases...

    https://www.phoronix.com/scan.php?pa...-42-Input-Rate

  • #2
    Finally. Can't believe it took GNOME this long.

    Now if only libinput devs would remove "your system is too slow" during delayed event processing in libinput...
    tildearrow
    Senior Member
    Last edited by tildearrow; 09 December 2021, 04:14 PM.

    Comment


    • #3
      How is KDE Plasma handling this? Is it possible to use a mouse like the Razer Viper 8khz with 8.000 Hz on KDE?

      Comment


      • #4
        GNOME 42 is going to be the biggest update in years. Even bigger than GNOME 40.

        Comment


        • #5
          Originally posted by tildearrow View Post
          Finally. Can't believe it took GNOME this long.

          Now if only Hutterer would change "your system is too slow" during delayed even processing in libinput...
          I suspect patches are welcome. Or paid wages.

          Otherwise namechecking a developer for features you want is not a good thing to do.

          Comment


          • #6
            Originally posted by You- View Post

            I suspect patches are welcome. Or paid wages.

            Otherwise namechecking a developer for features you want is not a good thing to do.
            And knowing how GNOME devs are, these patches wouldn't make it upstream without a lengthy argument, so there's no point on doing that.

            Here is proof: https://gitlab.freedesktop.org/libin...t/-/issues/613

            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.
            tildearrow
            Senior Member
            Last edited by tildearrow; 09 December 2021, 04:20 PM.

            Comment


            • #7
              Originally posted by EvilHowl View Post
              GNOME 42 is going to be the biggest update in years. Even bigger than GNOME 40.
              You remind me of 144Hz, btw what happened to him?

              Comment


              • #8
                Originally posted by tildearrow View Post

                And knowing how GNOME devs are, these patches wouldn't make it upstream without a lengthy argument, so there's no point on doing that.
                libinput isn't specific to GNOME or even Xorg or Wayland. So that comment doesn't make much sense even if your assumptions are true.



                Comment


                • #9
                  Originally posted by cl333r View Post

                  You remind me of 144Hz, btw what happened to him?
                  Well, I'm definitely not a troll and, unlike him, I don't really hate Qt and Plasma. I just enjoy GNOME more. But yeah, I haven't seen him in a while. He probably got banned or something.

                  Comment


                  • #10
                    Originally posted by tildearrow View Post

                    And knowing how GNOME devs are, these patches wouldn't make it upstream without a lengthy argument, so there's no point on doing that.

                    Here is proof: https://gitlab.freedesktop.org/libin...t/-/issues/613
                    How is that proof of anything when there is no patches to accept or decline in that gitlab issue? I'm also wondering what it is with that specific thread that you think is troublesome?

                    Comment

                    Working...
                    X