> 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/ _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel