Gamepad focus model (Re: Input and games.)

[Rick Yorgason]

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.

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

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!

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.

-Rick-