<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 6, 2013 at 5:10 PM, Rick Yorgason <span dir="ltr"><<a href="mailto:rick@firefang.com" target="_blank">rick@firefang.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Pekka Paalanen <ppaalanen@...> writes:<br>
> This design allows several gamepads associated with one wl_seat, and<br>
> thus one focus. It also allows gamepads to be assigned to different<br>
> seats, but then we will have more problems on managing the foci, not<br>
> unlike with keyboards. Hopefully there are no protocol design<br>
> implications, though.<br>
><br>
> From the game's point of view, it will need to iterate over all<br>
> wl_seats. For each seat with the gamepad capability bit set, create a<br>
> wl_gamepad_manager, receive all wl_gamepad objects, and for each<br>
> wl_gamepad receive the player id. Create your surfaces, wait for foci<br>
> to arrive, and fire away.<br>
<br>
</div>This all sounds good, and I certainly wouldn't try to block it, but I do<br>
have some thought experiments that lead to another solution.<br>
<br>
Incoming thought experiments, from least to most theoretical:<br>
<br>
Scenario 1) A typical single-user display server would likely only support<br>
one wl_seat, and assign all wl_gamepads to that seat. Games can iterate over<br>
them using wl_gamepad_manager. Great!<br>
<br>
Scenario 2) Two users are using a multi-user display server. Each user has a<br>
keyboard, mouse, and gamepad. User 2 has to set up their wl_seat using some<br>
configuration window built into the display server, but once that's done<br>
each user can jump in and out of a game as they see fit, assuming the game<br>
was written to iterate over wl_seats properly. Neat!<br>
<br>
Scenario 3) Two users are using gamepads with built-in touch screens (like<br>
the PS4 and OUYA controllers). The players don't care about the ability to<br>
have their own window focus, but the game wants to associate each touchpad<br>
with its gamepad. Player 2 must set up their own wl_seat in the display<br>
server, and must focus the game separately using the touchpad. Not ideal.<br>
<br>
You might say, "yeah, it's a bit of extra effort to set up player 2, but the<br>
cool thing is that player 2 can jump in and out of the game as they see<br>
fit!" Only that's not necessarily true either. Since many games steal the<br>
cursor, and player 2 has no keyboard, player 2 can jump into the game (using<br>
the touchpad on the controller) but can't jump out.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Scenario 4) In this scenario we imagine that wl_seat has grown support for<br>
wl_headset. Player 2 has an Xbox 360 controller with a headset plugged in.<br>
To support this, player 2 must go through the display server's wl_seat<br>
configuration to set up their own seat. Like in scenario 3, this is less<br>
than ideal. And how does player 2 focus the game without a keyboard or mouse?</blockquote><div>> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now, here's my alternate suggestion:<br>
<br>
* Drop wl_gamepad_manager.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Give wl_seat the ability to share focus with the default seat. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* A typical display server would add each gamepad to a new seat that shares<br>
focus with the default seat.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Multiple wl_seats is *the* way to support multiple controllers.<br>
<br>
Going through the scenarios again:<br>
<br>
Scenario 1) A single-user display would assign each wl_gamepad to a unique<br>
wl_seat that shares focus with the default seat. Games iterate through<br>
wl_seats to get each player. Cool.<br>
<br>
Scenario 2) On a multi-user display server, users can still use some<br>
configuration screen to set up their own mouse/keyboard/gamepad/focus,<br>
allowing them to jump in and out of the game as they see fit. As an added<br>
bonus, any multi-controller game is *guaranteed* to work properly under this<br>
setup, since the game programmer can't wrongly assume there's only one<br>
wl_seat. Great!<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Scenarios 3, 4) The display server can assume that devices attached to a<br>
gamepad should go into the same seat as that gamepad, and don't need to have<br>
their own focus. Player 2 is free to use their PS4/OUYA controller or<br>
headset in a game without any extra configuration. Cool!<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't know how much would get upset by allowing wl_seats to share focus,<br>
but it seems to be more general and future-proof than the wl_gamepad_manager<br>
solution.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>--Jason Ekstrand<br></div></div><br></div></div>