Gamepad focus model (Re: Input and games.)

[Peter Hutterer]

On Tue, May 07, 2013 at 11:14:08AM -0400, Todd Showalter wrote:
> 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.

in that case you'd be prone to having any number of gamepads in a
disconnected state until the server dies (unless you add timeouts,
etc).

tbh, I see the above as an application bug. Netflix is not a multiplayer
game, so it should handle a new gamepad gracefully (especially when the
first one re-appears). and games should too and give you the option of
re-configuring to match the target.

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

all of these should be handled in the client, IMO. the only thing wayland
should attempt is keep the identification stable if the gamepad
provides some physical ability to do so (i.e. so you can recognise the same
gamepad coming back).
 
Cheers,
   Peter

> 
> > 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.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>