Gamepad focus model (Re: Input and games.)

[Rick Yorgason]

Martin Minarik <minarik11 at ...> writes:
> Most common scenario would be:
>  A: joypad 1 on mother seat with keyboard and pointer
>  B: joypad 2 on child seat
> 
> Let's say:
> - user plugs another keyboard and pointer, udev assigns it
> to B:
> - weston promotes B: to mother seat
> The situation is as follows:
> 
>  A: joypad 1 on mother seat with keyboard and pointer
>  B: joypad 2 on mother seat with keyboard and pointer
> 
> The seats are now independent and can control the UI, user
> 2 can now quit
> the focus on the fly. But the question is.. Is this the
> expected?
> Let's say there is a full screen application and the user
> 2 presses alt+tab, now
> we have a surface stacking/ordering race.

To answer your question, yes, that is the expected behaviour. The original
purpose for wl_seat was to allow multiple users to have their own cursors,
their own window focus, and to share a desktop collaboratively. You've
described that scenario precisely.

Also, when you said "weston promotes B: to mother seat", were you implying
that this is an automatic response to the keyboard being assigned to B?
Because there's no reason for that to be the case. B could happily remain as
a child seat, and would simply have no way to change window focus. This
would be a perfectly sane thing to do if, for instance, you plugged a
keyboard into your gamepad.

I suspect most compositors would only create "mother" seats if the user
explicitly sets them up. If you plug a second keyboard into your computer,
there's no way for the compositor to guess whether you want it aggregated
with the first keyboard, or whether you want a second user, and aggregating
is the status quo right now.

-Rick-