Announcement

Collapse
No announcement yet.

Google Developers Working On Gaming Protocol For Wayland

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

  • Google Developers Working On Gaming Protocol For Wayland

    Phoronix: Google Developers Working On Gaming Protocol For Wayland

    Google developers are proposing the addition of a Gaming Input Protocol to Wayland...

    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
    Nice. We'd finally have a proper way for the screensaver to be suppressed in response to gamepad/joystick input rather than requiring some imperfect surrogate such as "suppress screensaver when something fullscreens" or "games/launchers are responsible for suppressing the screensaver".

    (Which would also mean that I could pause my game, walk away, and have the screens go to sleep normally)

    That said, boo on the W3C gamepad API's "Standard Gamepad" mapping. XInput is the new de facto standard on Windows and SDL's Gamepad API is making it the de facto standard on other platforms, but the W3C's solution is an inferior subset. (4 axes and 17 buttons can only represent XInput's 8 axes and 11 buttons if you represent the D-Pad as 4 buttons and downgrade the triggers from axes to buttons... though at least it can support everything a Steam Controller can say if you represent it as 16 buttons, four axes, and two sources of pointer events.)
    Last edited by ssokolow; 17 January 2017, 06:40 PM.

    Comment


    • #3
      Interesting. I wish Android would switch to glibc+Wayland instead of using bionic+Surfaceflinger.

      Someone should also develop a standard protocol for screen capturing and screenshots for Wayland. Otherwise, each compositor would need to come up with custom hacks for it, and writing a common portable application for those tasks that would work with different DEs would be close to impossible.
      Last edited by shmerl; 17 January 2017, 06:44 PM.

      Comment


      • #4
        Cool, after all these years a standardised gaming input protocol. Still a bit limited for now, for instance, I see no support for force feedback. I guess we will have to wait for the W3C specification to evolve.

        Comment


        • #5
          Interesting to see the likes of Google putting effort behind Wayland. They previously only cared about server linux, so this is a very interesting development.

          Comment


          • #6
            Looks like Wayland is becoming popular.

            I wonder how much time have to pass before Shuttleworth drops MIR for Wayland.

            Comment


            • #7
              DebianLinuxero wayland was popular from day1. Wayland came to change the way we sliced bread and everyone spread the news.
              As for amazon's adaware called ubuntu, it won't be long until they fork it and change it and add it to mir and never help the community.

              Comment


              • #8
                This all sounds VERY nice, save for one thing. I think?
                Does this sound like functionality that should be housed more into libinput than Wayland?
                I mean part of the reason for the move to wayland was to keep something like this from happening (which happened alot in X.org and because of the issue of backwards compatibility, kept being an issue).

                Or am I wrong?

                Comment


                • #9
                  Originally posted by ssokolow View Post
                  Nice. We'd finally have a proper way for the screensaver to be suppressed in response to gamepad/joystick input rather than requiring some imperfect surrogate such as "suppress screensaver when something fullscreens" or "games/launchers are responsible for suppressing the screensaver".

                  (Which would also mean that I could pause my game, walk away, and have the screens go to sleep normally)

                  That said, boo on the W3C gamepad API's "Standard Gamepad" mapping. XInput is the new de facto standard on Windows and SDL's Gamepad API is making it the de facto standard on other platforms, but the W3C's solution is an inferior subset. (4 axes and 17 buttons can only represent XInput's 8 axes and 11 buttons if you represent the D-Pad as 4 buttons and downgrade the triggers from axes to buttons... though at least it can support everything a Steam Controller can say if you represent it as 16 buttons, four axes, and two sources of pointer events.)
                  Actually it looks like the W3C API has an analogue (double) value for every button - it can express far more information than the SDL or XInput ones where the buttons are a single bit.

                  Comment


                  • #10
                    Originally posted by Duve View Post
                    This all sounds VERY nice, save for one thing. I think?
                    Does this sound like functionality that should be housed more into libinput than Wayland?
                    I mean part of the reason for the move to wayland was to keep something like this from happening (which happened alot in X.org and because of the issue of backwards compatibility, kept being an issue).

                    Or am I wrong?
                    If I understand things correctly, the protocol is for the transfer of information between libinput and the client application (and vise versa) (i.e. button push -> libinput -> wayland server -> <via this protocol> -> wayland client

                    Comment

                    Working...
                    X