[PATCH] protocol: Add gaming input protocol

[Peter Hutterer]

On Tue, Jan 24, 2017 at 05:51:26PM -0800, Roderick Colenbrander wrote:
> 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.

yeah, I'd say EV_LED is frozen, we're better off figuring out a way to
enable write support to sysfs. the situation is a bit different, 
unauthorized clients keeping an fd open to a LED sysfs file (because we
don't have EVIOCMUTE) is annoying but not a security risk. Unlike evdev,
where you could read key events.

it might be worth thinking about an abstraction layer to handle the LEDs,
this could either be in the compositor or through some daemon that manages
it.

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

battery bits are generally read-only, so it's relatively easy to access
that. but yes, gnome for example parses the /sys/class/battery files.

Cheers,
   Peter
> 
> > 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
> >