Gamepad focus model (Re: Input and games.)

[Jason Ekstrand]

On Thu, May 9, 2013 at 5:49 AM, Rick Yorgason <rick at firefang.com> wrote:

> Pekka Paalanen <ppaalanen at ...> writes:
> > 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.
>
> So, the purpose of wl_gamepad_manager is to allow multiple gamepads to
> share
> one application focus. That seemed weird to me (why is it only gamepads
> that
> would want that ability?) which is why I started thinking about wl_seat
> parenting, and I apologize if that caused more heat than light.
>
> But now I'm seriously wondering, does the compositor really need *any*
> protocol support to handle this case? I think we've been assuming that each
> seat will get its own free reign over the desktop, but isn't the compositor
> free to *not* do that? And instead to have some seats which only interact
> with the focused application?
>
> We could have one wl_gamepad per wl_seat, just like wl_pointer,
> wl_keyboard,
> or wl_touch, put the player ID in wl_seat instead of wl_gamepad, and give
> compositor writers a few suggestions:
>
> * Not all seats need to have a desktop pointer or the ability to control
> their own focus. It can be useful to allow "second class" seats which
> follow
> the focus of another seat, in which case neither the pointer nor any other
> event from that seat should be allowed outside of the focused application.
>
> * Each gamepad should automatically be put in a separate seat, either by
> putting it in an existing seat without a gamepad, or automatically creating
> a new seat.
>
> * If a seat is automatically created for a gamepad, it should ideally be of
> the "second class" type by default. Users can always reconfigure their seat
> if they want control over the desktop.
>
> Wouldn't that allow everything we want? It allows every user to have a full
> set of devices, and users don't have to worry about focus issues unless
> they
> want to. It also means the protocol doesn't need the contrivances of
> wl_gamepad_manager or seat parenting.


The more I think about this solution, the more I like it.  You're right
that clients have no reason to know why a seat gets focus, simply that it
does.  Also, it's worth remembering that whatever GUI we present to the
user doesn't have to directly correspond to the protocol.  From the user's
perspective, this would probably look like picking which pointing devices
actually get assigned to a pointer, and which seats correspond to which
pointer.

--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130509/f721f5da/attachment.html>