Input and games.

[Daniel Stone]

Hi,

On 5 May 2013 17:55, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 3 May 2013 17:42:20 +0100
> Daniel Stone <daniel at fooishbar.org> wrote:
>> tl;dr: wl_seat has a very specific meaning of a set of devices with
>> one focus, please don't abuse it.
>
> I'm not too clear on what it is.
>
> In a wl_seat, we have one kbd focus, and one pointer focus. These
> two are unrelated, except sometimes some pointer action may change
> the kbd focus. Most of the time, they have no relation.

'Most of the time'.  They are related though, occasionally affect each
other, and are not affected by the presence of, or actions from, other
seats.

> I was thinking of adding a third one: the gamepad focus. It could
> be independent from kbd and pointer foci, or maybe it is assigned
> with the kbd focus. Or maybe the gamepad focus is assigned to the
> surface having any wl_seat's the kbd focus, whose client has bound
> to the gamepad.
>
> In any case, we have the fundamental problem: which client gets the
> gamepad events at a point in time?
>
> There can be several clients bound to any gamepad, and the target
> (focus) must be switchable intuitively.
>
> Is it wrong to think a wl_seat as a user--a player, that may have a
> gamepad?
>
> It's just too tempting for me to think that each player corresponds
> to a particular wl_seat.

No, that's exactly right: one seat per user, hence the name (think
chair).  I don't think we need a separate gamepad focus; we could just
use the keyboard focus (or the pointer focus, if there's no keyboard,
or some magical compositor-specific metric if there's no pointer
either).

>> > This is a new situation, and so many open questions... I just continued
>> > on the exitisting pattern.
>>
>> Yeah, it really all depends on these questions.  But intuitively, I'd
>> say that gamepads should follow a seat's focus, which means expanding
>> wl_seat to be able to advertise multiple gamepads.  Even on touch, we
>> still have wl_touch as part of wl_seat, driving the focus.  And I
>> don't think a gamepad could ever be a part of multiple seats; perhaps
>> it could be shifted between seats if necessary, but this is a problem
>> we already have with keyboard, pointer and touch today.  And you don't
>> need to deal with that in the protocol: just have the compositor
>> destroy the device and create a new one in the new seat.
>
> Right, so if every wl_seat advertises every gamepad, how should the
> server route the gamepad input events? Should it be allowed to
> duplicate the events for every active wl_seat-binding of a gamepad?

I'm struggling to follow the leap between the previously quoted
paragraph (every player has likely one gamepad, every seat is exactly
one player), and this (every seat advertises every gamepad).  There is
definitely a need to be able to pin devices to a particular seat, and
move that pin, in the multiseat case, but that's no different to the
existing need to pin and move pointers and keyboards too.  And I
believe the answer is the same: that this protocol is unaffected, and
any moving mechanism would have to be a separate interface.

> Or, do we want to have a unique input event destination, and never
> duplicate events to several destinations?

We must never duplicate events to multiple destinations.  Imagine
pressing the start key and unpausing two games simultaneously.

> If every wl_seat advertises every gamepad, how do we avoid having a
> gamepad part of several wl_seats at the same time? When any client
> binds to any gamepad on any wl_seat, will the server then make
> that gamepad unavailable in all other wl_seats?
>
> We do not have this problem with keyboards and pointers, because
> keyboards and pointers are pre-assigned to wl_seats, and they do
> not change by client actions, nor do clients assume they can access
> all keyboards and pointers via the same seat. Unless, we think
> about having two separate pointers, and just one physical keyboard,
> and wanting to type for both pointers, one at a time. I don't
> recall any discussion of that, and I've just assumed it won't be
> implemented.

Well, a compositor could perfectly well implement that within the
protocol as it stands today.  But I wouldn't recommend it. :)

> **
>
> A very simple solution could be this (leveraging from your ideas):
>
> wl_gamepad_manager:
>
> A global interface, where you register wl_surfaces, and which
> advertises all gamepads in the session.
>
> wl_gamepad:
>
> Interface representing a single gamepad. Input events from the
> physical device are routed here, when any of the registered
> wl_surfaces have keyboard focus.
>
> There are some problems:
> - how to associate keyboards etc. with a player (gamepad)?
> - which seat's keyboard focus to follow?
> Seems that we have to involve the wl_seat somehow.
>
> Could this be a way forward?
>
> Or maybe wl_gamepad_manager is not a global itself, but when
> created, it gets bound to a specific wl_seat? Solves one problem,
> but introduces other ones...

For me, I'm thinking we add a gamepad bit to wl_seat::capabilities,
and wl-seat::get_gamepad, which returns new_id wl_gamepad.  Because,
as we've noted, we need a gamepad focus, and I don't believe that's
intrinsically different to the current seat focus model.

Assigning gamepads to the correct seat _is_ hard, but so is assigning
pointers and keyboards.

Cheers,
Daniel