Gamepad focus model (Re: Input and games.)

[Todd Showalter]

On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> Yeah, like Daniel said, there is no concept of a "return value".
>
> When a client creates a new object, the server can only either agree,
> or disconnect the client with a protocol error. Any other behaviour
> requires specialized handling, and causes a roundtrip, where the client
> must either wait for a reply before continuing, or risk having further
> requests ignored without any obvious way to know what got ignored in
> the end. Both cases are unacceptable.

    Ok.  I was assuming that cases where you had fundamental
capability change in the server (ie: input devices appearing or
disappearing) were rare and special enough to warrant a round trip.

> When a client sends a request, that creates a new protocol object, then
> from the client's point of view, the object is created on that instant,
> before the request has even been submitted to the wire. This allows the
> client to immediately send more requests on that new object, without
> waiting for a roundtrip in between. The same works also in the reverse
> direction, when the server creates protocol objects by sending events.
>
> A major design principle in Wayland is to minimize roundtrips, as it
> leads to better performance and lower overhead.

    Fair enough.  We're talking about rare events here, so I wouldn't
have called it essential, but if that's an organizing principle of the
project then so be it.

> It's not about the gamepad capabilities at all. It's just an
> assignment, configured in the server: this input device belongs to
> player N.

    The place where that becomes a problem is with controller
batteries.  As an example, I've got a PS3, and my wife uses it to
watch netflix (it's a streaming tv/movie service, for those who
haven't heard of it).  It uses the PS3 controller as a remote, to do
things like play/pause.

    It's not uncommon for the battery in the controller to run flat
while she's watching.  I've got a second controller, and we typically
charge one while the other is in use, but fairly often the controller
she's using runs flat.  When that happens, we have a second charged
controller, but to use it we have to reboot the PS3, because without
rebooting it connects as Player 2, and netflix only listens to Player
1.  As far as I know there's no simple way to tell the gamepad to
reconnect as Player 1, short of rebooting the machine and rerunning
all the controller handshaking.

    When a gamepad goes away and then it reappears or another appears,
it's *probably* the same player.  So what I'm thinking is that it
makes more sense to have the wl_gamepad go into a "disconnected"
state, and then reactivate when the next gamepad appears, rather than
creating a new wl_gamepad.

> If the gamepad later comes back "online", it is like it was hotplugged
> again: a new wl_gamepad object is sent, with the same player id as
> before.

    This would work too.  The main thing is dealing well with the
single player case where the player is replacing a gamepad.  This
could be because:

- they wandered out of RF range when they were getting a drink
- they want to play the game with a different gamepad
- the gamepad they were using ran out of power and is now plugged in via usb
- the gamepad they were using ran out of power and is being replaced
with a charged gamepad
- someone tripped over the usb cord and yanked it out and then plugged
it back in

> Yeah, the main point of the leave event is to say "you don't get any
> more input events from this device, until it comes back", and it also
> implies that the client should forget all temporary state of the
> gamepad, like which buttons were down.

    Yes.

> Immediately following an enter event, or in the enter event, a new set
> of current state is sent. Notice, that this should not be done by
> sending e.g. fake button-down events. We have a protocol design policy,
> that input events from user actions are never manufactured.

    My temptation would actually be to say that when focus goes to a
new application, we treat buttons that are down as if they were up;
don't send a release when they are lifted.  So, if I'm holding down
SELECT when focus enters the client window and then release it, press
it and release it, the client sees the press and the second release,
but not the initial release.

    That doesn't work with axis values, but if the client cares about
deltas it's going to have to clear them on focus change anyways, since
it has already been said that the protocol will not be sending deltas.
 If we were sending deltas we could make things a little cleaner in
some ways, but it does expand the protocol and I'm not sure it does so
usefully.

                                           Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.