Gamepad focus model (Re: Input and games.)

[Todd Showalter]

On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

    There are options here:

- have the capability bit, if the bit is set the client can request a
manager -- has to deal with the case where the client sent the request
but the caps bit wasn't set, presumably by returning NULL or -1 the
protocol equivalent

- leave out the caps bit, client requests the manager if they want it,
they get NULL equivalent if there are no gamepads

- leave out the caps bit, gampad manager is always there, but can be
expected to return 0 if asked to enumerate gamepads when none are
connected

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

    Some gamepads don't have player id controls, so we can't rely on
them, but supporting them where we can is useful.  I think it's best
viewed as a really forceful hint as to the player's ID, where
otherwise we're stuck doing heuristics with plugging.

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

    Dealing gracefully with things like wireless gamepads running
their batteries flat or moving out of radio range is important, which
is what I assume this is to deal with.  I presume the idea here is
that if the player moves back into range or replaces the batteries,
the wl_gamepad object revives?

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

    I think we need enter/leave events.  The client can be responsible
for cleaning up its own state, though if an initial state is sent on
focus gain that makes things much easier.

    I don't see anything here that raises any flags for me; at least
at first reading it seems quite usable.

                                            Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.