[PATCH] protocol: Add gaming input protocol

[Roderick Colenbrander]

On Mon, Jan 23, 2017 at 10:38 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Mon, Jan 23, 2017 at 07:24:24PM -0800, Roderick Colenbrander wrote:
>> 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.
>
> there's a different problem: we don't have access to write to LEDs in the
> compositor. we have logind for getting evdev access but we have nothing that
> gives us write-access to LEDs in sysfs. this only works for keyboard LEDs
> because we we can use EV_LED on the evdev node.

It would be nice if we could evolve EV_LED, the sysfs nodes are often
painful, but I doubt the input guys will like to change much.

A similar situation actually appears with battery through the
powersupply class on Linux. This kind of information may need to be
provided as well. 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.

> This is an issue we ran into during the tablet pad support. in that case we
> added LED support and handling to the kernel (because we had straightforward
> behaviour) so that we now only read it but don't have to write to it.
>
> so we need to figure out a few more bits and pieces, neither the fd passing
> nor a compositor protocol is sufficient for LED updates right now.
>
>> 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.
>
> Cheers,
>    Peter
>