[PATCH] protocol: Add gaming input protocol

[Mayeul Cantan]

Hi Jingqui,

>> 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").

> I agree that if there is a standard (or at least well known) set of actions, it
> will make things much easier, but I am afraid we are far from that.

I am sorry, I think I wasn't clear enough on this point. The idea here
was to allow games to dynamically define their actions. The backend
would only receive an identifier, and a collection of localized
strings to display in the configuration utility. This makes the set
virtually endlessly extensible. With that said, having a subset of
predetermined standard actions could also be useful, I guess, as it
would allow the player to carry their mappings from one game to
another, and leave the localization task to the backend.

> It will be absolutely wonderful if we have some shared library to define standard
> actions of games and unify the gamepad configuration and gameplay experience.
> But my question is, should it happen in the compositor?

The way I saw it was similar to the libinput one, with a shared
library sitting between the compositor and the kernel. The
configuration utility could then directly talk to this library (or
change configuration files). The compositor would also be a client of
this library for common interaction.

Now, we can ask ourselves if the games should talk to the compositor
to receive their input, or directly to the library. I think it would
make more sense if they talked to the compositor, as it is the way
other input methods are handled. Of course, this requires extending
the protocol (notably for setting up the callbacks and exporting the
action sets). But on the flip side, this would make the implementation
quite portable, and could allow developers (distribution and
compositor developers) to easily switch to an alternative controller
library if necessary.

Of course, this might not completely eliminate the need for direct
controller access, but I would expect most features (such as
filtering, combos, etc) to be built in the library.


Regarding the architecture of such a solution, the backend library
could handle the peripheral events at their nominal pooling frequency
using already existing kernel interfaces, filtering out the relevant
events according to what could be a configuration file passed by the
compositor (which would depend on the active application, for
example). The library would then pass on the matching events to the
compositor, which would forward them to the active application.

Here is one example, taking into account the remark on shared action
sets (please keep in mind that this is just a possible implementation,
as an example, and is very rough):
1. Compositor startup. Registers the "desktop configuration" with the library
2. Client startup. Attaches to the compositor, then requests "game01
configuration". It can specify a default config file.*
3. When the game01 client is active, the compositor registers the
appropriate config file (possibly changed or tweaked by the user) with
the library
4. A button is pressed on the controller, which matches one of the
actions, as per the config file.
5. The library forwards the action to the compositor, which forwards
it to the game01 client

* Here is an example of action set that game01 could request:

ID                type          string (localized if necessary)
0x01            bool          jump
0x02            analog       horizontal aim
0x3F            analog[2]   minimap position
0x80000001  bool          equip BFG1
0x80000002  bool          summon Ally1

An ID range could be used for some predetermined "common controls"
that could share some properties between games (preferred mappings,
already translated descriptions, etc).

And of course, a mechanism should allow the compositor to query the
idle time as well, to ensure screen lock prevention.
I would be curious to hear your opinion on such a system.

>> Many of the features I previously described are very common (on most
>> gamepads since first Xbox / Wii) and I don't think we should dismiss
>> right away. Some of the cheap clone controllers often lack them, but
>> if you look at market share all the major ones have them (touchpad is
>> more exotic, I admit).
>
> exotic? isn't it a default feature of (one of) the most popular gaming
> consoles out there? :) I'd say that whatever ps/xbox provide, should be
> considered the standard feature set.

Regarding the LEDs, I just want to point out the obvious fact that
some controllers such as the Steam controller and the Xbox ONE
controller (as far as I know) lack them. There is also the issue of
overflowing the indicator, which can arise (for example, when five
xbox 360 controllers are plugged in at the same time). On Linux, those
LEDs are controlled by the driver, and set up at the connection.
Should these be controllable by the games themselves? I guess that
having this feature available wouldn't hurt, but that's not the most
used one nor the most useful, as far as I know.

> How is this currently doing for like a wireless
> keyboard, mouse, tablet? Maybe it is not considered so much, because
> often batteries last a very long time. Gamepads are more likely to
> last maybe 12 hours, probably even half of that.

On Linux (and some other Unixes, actually), this is exposed by Upower,
which has multiple backends:
https://cgit.freedesktop.org/upower/tree/src/linux
Some controllers already report their battery level, such as the
wiimotes (see https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-wiimote-modules.c
for the kernel implementation).

Best regards,

Mayeul