Announcement

Collapse
No announcement yet.

Libinput 1.4 Marks The Project Being "Done" For Its Original Goals

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

  • Libinput 1.4 Marks The Project Being "Done" For Its Original Goals

    Phoronix: Libinput 1.4 Marks The Project Being "Done" For Its Original Goals

    With this week's release of libinput 1.4, Peter Hutterer has announced "libinput is done", at least in terms of its original goal.s..

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    What if I want to use a gamepad, joystick, or a eye tracker?

    Comment


    • #3
      I just read his blog post, such a great milestone!

      Also, little typo:
      With this week's release of libinput 1.4, Peter Hutterer has announced "libinput is done", at least in terms of its original goal.s

      Comment


      • #4
        Originally posted by uid313 View Post
        What if I want to use a gamepad, joystick, or a eye tracker?
        While it could be extended to do that, a secondary library that sits next to libinput (that looks practically the same in a lot of regard) is possible. Libraries access input dev nodes directly (SDL comes to mind), there is no need to go through the windowing system.

        Comment


        • #5
          I'm just waiting on relative mouse movements because I've noticed that (for Minecraft + 191 mods at least) there are way fewer graphical glitches. E.g. on Gnome Antergos X11, trying to fullscreen in MC will turn the screen black completely while it works fine on Wayland/XWayland.

          Comment


          • #6
            libinput still sucks as xorg server input. its simply impossible to play tomb raider (and some more games) with libinput because "minimal" mouse movements will be ignored ingame. so shooting sessions are no fun

            Comment


            • #7
              Congratulations Peter.

              Comment


              • #8
                Originally posted by uid313 View Post
                What if I want to use a gamepad, joystick, or a eye tracker?
                I am also bored to not seeing a good solution for gamepad, so I started to develop a library for handling gamepad. I have in mind two goals, provide a proper interface for handling gamepad and provide some wrappers to make older games using it with different techniques (ptrace /dev/input, wine dinput, wine xinput ...). The library is far from being in usable state, there is a lot of work to do, any help is welcome. https://gitlab.com/corossig/LibGamepad

                Comment


                • #9
                  Originally posted by computerquip View Post

                  While it could be extended to do that, a secondary library that sits next to libinput (that looks practically the same in a lot of regard) is possible. Libraries access input dev nodes directly (SDL comes to mind), there is no need to go through the windowing system.
                  Which is kind of unfortunate IMO if you're dealing with multiple windows, because for normal input you only get window-specific events, which makes handling them easier. Gamepad inputs, OTOH, need to be treated as global events, and I have to manually match based on windows focus where they're supposed to go.

                  Admitted, this is an extremely fringe case that probably not many people other than me have hit, however I do think it's kind of strange that an unfocused game would still consume gamepad input events when mouse/keyboard have no effect on it.

                  Comment


                  • #10
                    Why is it only just "done" at version 1.4? Shouldn't version 1.0 be the mark of completing all of the original goals?

                    Comment

                    Working...
                    X