[PATCH] protocol: Add gaming input protocol

[Roderick Colenbrander]

On Mon, Jan 23, 2017 at 2:05 PM, Jingkui Wang <jkwang at google.com> wrote:
> 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?

Yes, in general clients utilize these kind of features. There are edge
cases like playerid assignments in which maybe something outside the
direct client sets e.g. led states to player 1, 2,..

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

Some of the features don't easily work over fds. The best example are
leds, for which applications have to deal with sysfs nodes.
Hypothetically if clients were to deal with these, they would need to
be passed hardware bus ids and other fields to be able to locate the
device. I don't think is desirable at all and would have to be done
over a protocol.

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

>
> 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



-- 
Roderick Colenbrander
Senior Manager of Software Engineering
Gaikai, a Sony Interactive Entertainment Company
roderick at gaikai.com