[PATCH] protocol: Add gaming input protocol

[Mayeul Cantan]

> Gaming input protocol works as an extension to support gaming devices.
> Currently, it only supports game pad.

Hi,

I am sorry to chime in, especially since I am not really familiar with
that matter, nor with the Wayland protocol in general. But from what I
understood of this protocol, there might actually be a better way of
handling controller input.

There is a huge variety of game controls and game controllers out
there (with buttons, axis, touch surfaces, gyros, accelerometers,
cameras, sliders, switches, triggers, etc), and applications are
usually required to do the bindings themselves.
I like a bit more the approach taken by VALVe on the topic. I do not
have access to the steam controller API, so I will just attempt to
superficially describe it with my current understanding:
games usually have a defined set of actions, in different contexts
(take for example a game where the player can be in a menu, driving a
boat or flying a plane; those are the contexts or "action sets"). So,
instead of letting the application do the binding, it exports the
actions and the current action set, and let a dedicated input layer do
the bindings as configured by the user. In the end, the game or
application only gets *events*, no raw keycodes. The application also
has a way to request an informative bitmap to represent the key to the
user, and the name of the said key.

This description is from my basic understanding of the system.

There are multiple advantages to this approach:
 - The same game can support a lot of different controllers
"natively", which has always been a problem in the past,
 - Configuration tools can be perfectly adapted to some gamepad, and
present it in an interactive way to the user, instead of some
half-backed in-app binding utility,
 - The user can remap every control as he sees fit, with some room for
more complex trigger systems (ie, two key presses, on-screen displays,
etc),
 - In-game tooltips are always displayed for the right controller type,
 - Controller-agnostic force feedback could be integrated into the
API, though this would probably be more difficult.

As for the disadvantages:
 - Less control on input from the developer (there could be some way
of manually querying the ray controller data, but the use case is
small),
 - More complex handshake procedure, when the game has to export its
"actions" and "action sets",
 - More complex libraries required outside of the game (this is
probably the biggest drawback)*,
 - Passing around bitmaps could be expensive, depending on the
protocol, but it shouldn't be that frequent of a need. Plus, there is
opportunity for caching.

That's all I can think of for now, as I am writing this mail rather
quickly. You might have already heard of this solution; if so, I would
be curious to know if it could work as the preferred controller input
method in a Wayland world; and if not, what are the blockers. I also
have a couple of ideas regarding possible implementations, and would
be glad to help however I can, so feel free to ask.

Have a nice day.


Best regards,

Mayeul

* Some developers asked VALVe to open-source the steam controller, at
various levels (including the API, I believe). It would probably be
wise to try to get in touch with VALVe and some game developers about
that. See [0] for a developer's thread on reddit.

[0] https://www.reddit.com/r/SteamController/comments/5mdpb9/an_affirmative_business_case_for_valve_to_open/