Gamepad focus model (Re: Input and games.)

[Pekka Paalanen]

On Tue, 7 May 2013 11:14:08 -0400
Todd Showalter <todd at electronjump.com> 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.

They can be rare, but they can also happen any time.

> > 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, sure, and that's all just heuristics inside the server. The
server needs to make sure the player id becomes what the user
wants, even if one wl_gamepad object is deleted and another created.

The server will have the same problem even if it was supposed to
revive a dead wl_gamepad object, anyway.

The problem you described with PS3 should be solvable with the
mysterious gamepad configuration GUI I talked about before, somehow.

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

It depends. If a gamepad enters with button A down, and then the
user presses button B down, is the application supposed to respond
to B or A+B?

I'm not sure what wl_keyboard does, but it needs at least some keys
handled in current state, like shift. wl_pointer OTOH never had
this problem, since pressing down a button activates an implicit
grab, which means the wl_pointer device can never change focus with
buttons down. Well, almost never.

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

Right, better send the values as closest to their physical
interpretation. Mouse motion is always relative, and a stick axis
or a button is always absolute. Absolute valued inputs may all need
initial state sent.


Thanks,
pq