On Tue, 14 May 2013 04:49:39 +0000 (UTC) Rick Yorgason <[email protected]> wrote:
> Daniel Stone <daniel@...> 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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
