Gamepad focus model (Re: Input and games.)

[Jason Ekstrand]

On Mon, May 6, 2013 at 5:10 PM, Rick Yorgason <rick at firefang.com> wrote:

> Pekka Paalanen <ppaalanen at ...> writes:
> > This design allows several gamepads associated with one wl_seat, and
> > thus one focus. It also allows gamepads to be assigned to different
> > seats, but then we will have more problems on managing the foci, not
> > unlike with keyboards. Hopefully there are no protocol design
> > implications, though.
> >
> > From the game's point of view, it will need to iterate over all
> > wl_seats. For each seat with the gamepad capability bit set, create a
> > wl_gamepad_manager, receive all wl_gamepad objects, and for each
> > wl_gamepad receive the player id. Create your surfaces, wait for foci
> > to arrive, and fire away.
>
> This all sounds good, and I certainly wouldn't try to block it, but I do
> have some thought experiments that lead to another solution.
>
> Incoming thought experiments, from least to most theoretical:
>
> Scenario 1) A typical single-user display server would likely only support
> one wl_seat, and assign all wl_gamepads to that seat. Games can iterate
> over
> them using wl_gamepad_manager. Great!
>
> Scenario 2) Two users are using a multi-user display server. Each user has
> a
> keyboard, mouse, and gamepad. User 2 has to set up their wl_seat using some
> configuration window built into the display server, but once that's done
> each user can jump in and out of a game as they see fit, assuming the game
> was written to iterate over wl_seats properly. Neat!
>
> Scenario 3) Two users are using gamepads with built-in touch screens (like
> the PS4 and OUYA controllers). The players don't care about the ability to
> have their own window focus, but the game wants to associate each touchpad
> with its gamepad. Player 2 must set up their own wl_seat in the display
> server, and must focus the game separately using the touchpad. Not ideal.
>
> You might say, "yeah, it's a bit of extra effort to set up player 2, but
> the
> cool thing is that player 2 can jump in and out of the game as they see
> fit!" Only that's not necessarily true either. Since many games steal the
> cursor, and player 2 has no keyboard, player 2 can jump into the game
> (using
> the touchpad on the controller) but can't jump out.
>

I think this is where a judicious use of the "home" button could come in
very handy.  As long as the game is nice and releases the mouse on "home",
or the compositor takes over or something, the problem is solved.


> Scenario 4) In this scenario we imagine that wl_seat has grown support for
> wl_headset. Player 2 has an Xbox 360 controller with a headset plugged in.
> To support this, player 2 must go through the display server's wl_seat
> configuration to set up their own seat. Like in scenario 3, this is less
> than ideal. And how does player 2 focus the game without a keyboard or
> mouse?

>

> Now, here's my alternate suggestion:
>
> * Drop wl_gamepad_manager.
>

Personally, I don't see why we need wl_gamepad_manager in order to have
multiple gamepads.  Why can't we have a get_gamepads request to which the
seat respons with a gamepad event.  Then again, the extra protocol object
isn't that bad either.


> * Give wl_seat the ability to share focus with the default seat.
>
* A typical display server would add each gamepad to a new seat that shares
> focus with the default seat.
>

I don't think we should restrict this to "default".  Effectively, we would
need a way for a seat to have a "parent" seat from which it derives its
focus.  This may get to be a mess especially from a user-interface
perspective.  Perhaps you could have a "automatically parent to whatever my
default is" paradigm.  However, for more interesting configs, it get a lot
more confusing.  See below.


> * Multiple wl_seats is *the* way to support multiple controllers.
>
> Going through the scenarios again:
>
> Scenario 1) A single-user display would assign each wl_gamepad to a unique
> wl_seat that shares focus with the default seat. Games iterate through
> wl_seats to get each player. Cool.
>
> Scenario 2) On a multi-user display server, users can still use some
> configuration screen to set up their own mouse/keyboard/gamepad/focus,
> allowing them to jump in and out of the game as they see fit. As an added
> bonus, any multi-controller game is *guaranteed* to work properly under
> this
> setup, since the game programmer can't wrongly assume there's only one
> wl_seat. Great!
>

Ok, let's bump this a step further and say that you have four controllers
and two mice/keyboards.  You want to have 2 gamepads for each mouse.  Now
we have a problem since only the "default" focus can have multiple gamepads
associated with it.  Like I said above, this can be solved by having a
parenting structure for seats.


> Scenarios 3, 4) The display server can assume that devices attached to a
> gamepad should go into the same seat as that gamepad, and don't need to
> have
> their own focus. Player 2 is free to use their PS4/OUYA controller or
> headset in a game without any extra configuration. Cool!
>

Having the two controllers paired doesn't solve 3.  There are a lot of UI
problems with having two pointers running around the screen that share a
focus.  Let's say they're one of those crazy users that like sloppy-focus.
What happens when the two cursors are on different windows?  Does the
primary cursor over-ride?  Does the secondary cursor work in windows that
aren't focused?  Even if you have click-to-focus, you still have problems
with the two cursors fighting.  What happens if they both try to do a
drag-and-drop?  The only solution to this is probably to make the secondary
pointer inert in windows that aren't focussed.  That said, I'm not sure if
that 100% fixes it either.


> I don't know how much would get upset by allowing wl_seats to share focus,
> but it seems to be more general and future-proof than the
> wl_gamepad_manager
> solution.
>

To tie up my comments, I think this can get far too complicated fast.  I
think it's better to have a seat correspond to a focus and allow for the
fact that we may have more than one person to a seat.  It's not 100% ideal,
but it's a lot simpler than some strange tree of seats.  Besides, if some
compositor wants to do a strange tree of seats, there's nothing in pq's
proposed protocol that would prevent that and games shouldn't care.

--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130506/576439e9/attachment-0001.html>