Gamepad focus model (Re: Input and games.)

[Pekka Paalanen]

On Thu, 9 May 2013 16:44:09 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote:
> [...]
> > 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.
> 
> do you expect the player ID to be exposed on the protocol?
> what does it contain and who manages the association?
> is it related to any physical ID of the gamepad, and if not, can such ID be
> provided (if the device supports it)?

I imagined the player ID to be sent explicitly in the protocol, with
its very own event. The server would manage the association between
physical devices and the player ID, according to built-in heuristics
and user preferences.

E.g. if one goes from 0 gamepads to 1 gamepad, it will always be player
1; or maybe take the first player slot that does not have a gamepad,
unless we identify the device as the same that was recently unplugged
in which case take the player slot that it used to have. Or something,
with user preferences, and some UI to fix the association in the rare
case when the heuristics choose wrong.

Recognizing a gamepad could be done via physical identification, if one
is available, or by usb port/hub, or whatever platform specific way.
The clients would not have to care, they would only work with unique
player IDs, which are integers created in sequence starting from 1 (or
0).

Using integers starting from 1 makes it trivial for the server to
update the player ID display on the gamepads, if they have one.

The server could also implement a global UI to reassing gamepads. For
instance, press the famous home button for 5 secs on any gamepad, get
some gamepad controllable GUI to reassing them, or maybe just a request
to press the home button again on each gamepad in sequence.

Doing all this client side would mean we need to find a way to
communicate all the device and platform specific hints for the gamepad
assignment heuristics somehow, and each client instance would have its
own gamepad assignments.

> is the player ID not better represented through a wl_seat? - if you're
> playing a full-screen game, both seats can safely have the same focus,
> otherwise, players can play games independently.
> plus, if both players have a separate seat, they can use their keyboard
> independently for data entry.

Those were exactly my thoughts in the beginning, however during the way
long email thread, I got convinced otherwise for now. There are a few
issues that come mind:
- how to know, when one seat should follow the keyboard(?) focus of
  another seat?
- a client still needs to map seats into players; how? does it need an
  UI to fix it in case a user is not happy with the result?

Also, allowing multiple gamepads in one seat does not exclude the seat
approach. A server could still assign every gamepad to a different
seat, provided it had some way to solve the focus assignment.

In any case, I think the player ID assigned to each gamepad by the
server is useful, since it would solve the seat<->player mapping, too.
Although, in a strict one gamepad per seat setting it would be better
suited as a seat event than a gamepad event, perhaps.


Thanks,
pq

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