Gamepad focus model (Re: Input and games.)

[Rick Yorgason]

Daniel Stone <daniel at ...> writes:
> I know I've had some trouble expressing my problems with the
> every-gamepad-in-a-seat proposal, but this pretty much hits the nail
> on the head.  How does the gamepad's focus get assigned (and change)
> if it's in its own seat? Does it always follow the focus of another
> wl_seat? If so, why have we created another wl_seat? Is it only to
> contain a wl_gamepad and nothing else - if so, why are we using seats
> as an indirection layer? Or do some gamepads go into the seat with the
> pointer and keyboard and others go into their own seats - if so, isn't
> that totally arbitrary and more than a little confusing?

Okay, so the most common configuration would be one seat with a mouse,
keyboard, and gamepad. If you only ever play single player games, this is
all you would see.

When you have multiplayer games, you just want to be able to launch the game
and have everybody automatically in it. You don't want your extra players to
have to think about focusing the app or anything like that.

That's the crux of the problem: how do you have one focus for multiple
players? The many-gamepads-per-seat model solves this, but it has a couple
problems:

1) Some compositors may put every gamepad in one seat, and some compositors
may assign one gamepad per seat. The game programmer has to support both
code paths. And unfortunately, when game programmers inevitably neglect to
do that, the gamers are going to blame the compositors rather than the
games. Wayland will get a reputation as a display server where you have to
configure your gamepads differently for different games.

2) Gamepads aren't the only scenario where you want to have one focus for
multiple players.

Here's a couple scenarios that are complicated by breaking the seat == user
model:

A) You're playing split-screen Halo. Two users have a mouse/keyboard, and
two users have gamepads.

In the seat == user world, we know how this is set up: seat 1 has a
mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and seat
4 has a gamepad.

In the many-gamepads-per-seat model, I don't know how to set this up. The
first two players would have to have their own seats, but since the player
ID is in the gamepad, where do we get their player numbers from? And what
about players 3 and 4? Where do their gamepads go? They can go in seat 1,
but then how do you distinguish player 1 from players 3 and 4? And why does
player 2 have to manually focus the game?

(I don't believe this scenario is inherently exotic. Lemmings, Settlers, and
Hired Guns all did this back in the DOS and Amiga days, before OSs made it
harder to distinguish mice from each other.)

B) Imagine that, with the current trend of adding touchpads to gamepads,
Fruit Ninja releases a multi-player version. All players play on the same
"field", but it tracks their scores independently; whomever slashes the
fruit first gets the points. Let's imagine we have player 1 with a separate
touchpad, and players 2 and 3 with gamepads that have touchpads built in.

In the seat == user model, it's obvious how this should be set up: seat 1
gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and so
does seat 3.

In the many-gamepads-per-seat model, the question rises again of where you
put the gamepads. Do they go in the same seat as the touchpad they're
attached to? Or do they all end up in seat 1? If they're all in seat 1, does
the player indicator on their controller match up with their actual player
number? And again, they all have to individually focus the game.

> If the focus can be changed independently, how does this happen?

Focus can only be changed independently for "collaborative" seats.
"Collaborative mode" means "I want to interact with the desktop
independently." When collaborative mode is turned off, your focus is derived
from a seat which *is* in collaborative mode.

> If
> the keyboard/pointer seat switches focus to another game, do both
> seats switch, or does the other stay behind?

Assuming seat 2 is following seat 1, they both switch.

> If both switch - why are
> we complicating the focus model rather than just adding both to a
> seat?

Because this problem doesn't start and end with gamepads. If we take the
multiple-gamepads-per-seat model to its logical conclusion, then to support
the scenarios above, you would also need multiple mice/keyboards/touchpads
per seat. And then how do you determine which devices belong to which players?

> The wl_seat == one player idea is a nice little mental model, but it's
> not in any way worth complicating our core input/focus management
> model for.

I believe we're both trying to avoid complication :)

-Rick-