Gamepad focus model (Re: Input and games.)

[Daniel Stone]

Hi,

On 9 May 2013 11:49, Rick Yorgason <rick at firefang.com> wrote:
> 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?

Yes, the mechanics of how focus is set and transferred are
unspecified, thankfully.

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

Seats without wl_pointer already don't have a desktop pointer, and
seats don't necessarily control their own focus.  What happens when
the compositor transfers focus is very well-defined.  But nowhere in
the protocol does it specify when focus is transferred, because
without a view of the full window tree, clients don't have enough
context to know what would happen anyway.  So this is a moot point.

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

That's not the point of a seat right now.  But this is totally doable
without any compositor changes if you want, and the client doesn't
ever need to know about it.

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

Why put it in a seat, then? If it's not going to go in with a
keyboard, mouse or touch device, don't bother with the seats, just
keep it as a separate object.  The purpose of seats was to aggregate
and relate input devices.  If all you're doing with wl_seat is using
it as a shim to carry one (_exactly_ one) object, why bother?

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

Again, doesn't require protocol changes.

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

I don't see what it brings us, if I'm honest.

I guess it all hinges on how the focus model is implemented, and to
what extent we want to express that through the protocol.  *shrug*

Cheers,
Daniel