[PATCH] protocol: Add gaming input protocol

[Jingkui Wang]

On Fri, Jan 20, 2017 at 2:22 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> Hi all,
>
> sorry for the fly-by commenting, but I would like to mention an idea
> that has popped up in the past for game controller support, IIRC on
> wayland-devel at .

Thanks, Pekka. I would like first to describe what I am working on and
why our approach pops up naturally.
I am working on arc++ to support gamepads (some background here:
https://lwn.net/Articles/701964/). Gamepad events are read in Chrome
and routed to Android through Wayland. Android expose gamepad input to
game developers through Android api:
 (https://developer.android.com/training/game-controllers/controller-input.html)

Naturally, it worked well for us to read/process/remap events in
compositor, and send button/axis events.

> That idea was that the compositor would not translate everything into
> Wayland protocol. Instead, the compositor would hand out open evdev
> device file descriptors to applications when game controller focus is
> given, and revoke those file descriptors (make them dead) when game
> controller focus is taken away.
> (Hmm, do we have a mechanism to revoke fds or was that never merged in
> the kernel?)
>
It sounds like this will also solve Roderick's concern? (Correct me if
I am wrong, the client will utilize "non-standard gamepad" functions
like rumble/led?
I strong agree with the idea of exposing/revoking fd to support
additional features, while I think we can translate the standard
features to wayland-protocol.

The client might choose to consume only standard set of gamepad events
or take the fd and get a full set of capabilities. Exposing the
"standard set" will save the client from understanding the kernel and
using toolkit/library. If some
feature becomes so common, maybe we can move on to add it into the
"standard set".

Thanks,
Jingkui