[PATCH] protocol: Add gaming input protocol

Peter Hutterer peter.hutterer at who-t.net
Tue Jan 24 06:38:03 UTC 2017

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.

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.


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

More information about the wayland-devel mailing list