Gamepad focus model (Re: Input and games.)

[Pekka Paalanen]

On Mon, 6 May 2013 11:01:28 +0100
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On 5 May 2013 17:55, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Fri, 3 May 2013 17:42:20 +0100
> > Daniel Stone <daniel at fooishbar.org> wrote:
> >> tl;dr: wl_seat has a very specific meaning of a set of devices with
> >> one focus, please don't abuse it.
> >
> > I'm not too clear on what it is.
> >
> > In a wl_seat, we have one kbd focus, and one pointer focus. These
> > two are unrelated, except sometimes some pointer action may change
> > the kbd focus. Most of the time, they have no relation.
> 
> 'Most of the time'.  They are related though, occasionally affect each
> other, and are not affected by the presence of, or actions from, other
> seats.
> 
> > I was thinking of adding a third one: the gamepad focus. It could
> > be independent from kbd and pointer foci, or maybe it is assigned
> > with the kbd focus. Or maybe the gamepad focus is assigned to the
> > surface having any wl_seat's the kbd focus, whose client has bound
> > to the gamepad.
> >
> > In any case, we have the fundamental problem: which client gets the
> > gamepad events at a point in time?
> >
> > There can be several clients bound to any gamepad, and the target
> > (focus) must be switchable intuitively.
> >
> > Is it wrong to think a wl_seat as a user--a player, that may have a
> > gamepad?
> >
> > It's just too tempting for me to think that each player corresponds
> > to a particular wl_seat.
> 
> No, that's exactly right: one seat per user, hence the name (think
> chair).  I don't think we need a separate gamepad focus; we could just
> use the keyboard focus (or the pointer focus, if there's no keyboard,
> or some magical compositor-specific metric if there's no pointer
> either).
> 
> >> > This is a new situation, and so many open questions... I just continued
> >> > on the exitisting pattern.
> >>
> >> Yeah, it really all depends on these questions.  But intuitively, I'd
> >> say that gamepads should follow a seat's focus, which means expanding
> >> wl_seat to be able to advertise multiple gamepads.  Even on touch, we
> >> still have wl_touch as part of wl_seat, driving the focus.  And I
> >> don't think a gamepad could ever be a part of multiple seats; perhaps
> >> it could be shifted between seats if necessary, but this is a problem
> >> we already have with keyboard, pointer and touch today.  And you don't
> >> need to deal with that in the protocol: just have the compositor
> >> destroy the device and create a new one in the new seat.
> >
> > Right, so if every wl_seat advertises every gamepad, how should the
> > server route the gamepad input events? Should it be allowed to
> > duplicate the events for every active wl_seat-binding of a gamepad?
> 
> I'm struggling to follow the leap between the previously quoted
> paragraph (every player has likely one gamepad, every seat is exactly
> one player), and this (every seat advertises every gamepad).  There is
> definitely a need to be able to pin devices to a particular seat, and
> move that pin, in the multiseat case, but that's no different to the
> existing need to pin and move pointers and keyboards too.  And I
> believe the answer is the same: that this protocol is unaffected, and
> any moving mechanism would have to be a separate interface.
> 
> > Or, do we want to have a unique input event destination, and never
> > duplicate events to several destinations?
> 
> We must never duplicate events to multiple destinations.  Imagine
> pressing the start key and unpausing two games simultaneously.
> 
> > If every wl_seat advertises every gamepad, how do we avoid having a
> > gamepad part of several wl_seats at the same time? When any client
> > binds to any gamepad on any wl_seat, will the server then make
> > that gamepad unavailable in all other wl_seats?
> >
> > We do not have this problem with keyboards and pointers, because
> > keyboards and pointers are pre-assigned to wl_seats, and they do
> > not change by client actions, nor do clients assume they can access
> > all keyboards and pointers via the same seat. Unless, we think
> > about having two separate pointers, and just one physical keyboard,
> > and wanting to type for both pointers, one at a time. I don't
> > recall any discussion of that, and I've just assumed it won't be
> > implemented.
> 
> Well, a compositor could perfectly well implement that within the
> protocol as it stands today.  But I wouldn't recommend it. :)
> 
> > **
> >
> > A very simple solution could be this (leveraging from your ideas):
> >
> > wl_gamepad_manager:
> >
> > A global interface, where you register wl_surfaces, and which
> > advertises all gamepads in the session.
> >
> > wl_gamepad:
> >
> > Interface representing a single gamepad. Input events from the
> > physical device are routed here, when any of the registered
> > wl_surfaces have keyboard focus.
> >
> > There are some problems:
> > - how to associate keyboards etc. with a player (gamepad)?
> > - which seat's keyboard focus to follow?
> > Seems that we have to involve the wl_seat somehow.
> >
> > Could this be a way forward?
> >
> > Or maybe wl_gamepad_manager is not a global itself, but when
> > created, it gets bound to a specific wl_seat? Solves one problem,
> > but introduces other ones...
> 
> For me, I'm thinking we add a gamepad bit to wl_seat::capabilities,
> and wl-seat::get_gamepad, which returns new_id wl_gamepad.  Because,
> as we've noted, we need a gamepad focus, and I don't believe that's
> intrinsically different to the current seat focus model.
> 
> Assigning gamepads to the correct seat _is_ hard, but so is assigning
> pointers and keyboards.

So... have we been violently agreeing the whole time? :-D

I had a private chat with Daniel, and we came to an understanding,
which I try to describe below. The interface names below are more like
placeholders for now.

Into wl_seat, we should add a capability bit for gamepad. When the bit
is set, a client can send wl_seat::get_gamepad_manager request, which
creates a new wl_gamepad_manager object. (Do we actually need a
capability bit?)

A wl_gamepad_manager will send an event for each physical gamepad (as
it dynamically appears, if hotplugged later) associated with this
particular wl_seat, creating a wl_gamepad object for each.

A wl_gamepad object will send an event about the player id as the first
thing, and also if it later changes.

If a gamepad is hot-unplugged, a wl_gamepad event will notify about
that, and the wl_gamepad object becomes inert (does not send any
events, ignores all but the destroy request).

Associating physical devices into wl_seats is left as a server detail.
The only rule is, that a physical device can appear at most in one
wl_seat at a time. The server is free to move e.g. gamepads from one
seat to another at runtime, clients will just see one gamepad
hot-unplugged, and one hotplugged later under a different seat.

Gamepad input events are delivered according to the keyboard focus of
the related wl_seat. If there is no keyboard to focus, then use the
pointer focus, or something. It doesn't really affect the protocol
design how the focus is assigned. However, would we need a
wl_gamepad::enter,leave events? Probably, along with events for initial
state. Or maybe enter/leave should be wl_gamepad_manager events?

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.


Thanks,
pq