Gamepad focus model (Re: Input and games.)

[Pekka Paalanen]

On Tue, 14 May 2013 04:49:39 +0000 (UTC)
Rick Yorgason <rick at firefang.com> wrote:

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

this makes sense to me, FWIW. Having proper concepts for describing how
a server could assign foci is what was missing. The protocol is a
separate thing anyway, and max one gamepad per wl_seat makes the
protocol simpler while leaving the focus assignment problem free to be
solved any way is best. I think we can all agree, that the focus problem
is still perfectly solvable with the one gamepad per seat protocol
model, right?


Cheers,
pq

ps. Rick, please use reply-to-all.