Input and games.

[Pekka Paalanen]

On Tue, 30 Apr 2013 09:14:48 -0400
Todd Showalter <todd at electronjump.com> wrote:

> On Tue, Apr 30, 2013 at 5:29 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> 
> > you've provided lots of valuable information already. Unfortunately
> > my input is left as hand-waving, since I cannot dedicate to
> > designing this protocol myself (as in writing the XML spec).
> 
>     I'm getting set up to write code.  Someone kindly gave me a bash
> script to pull down all the components, so once I get things set up
> properly I'll see if I can get a patch together.

Excellent!

> >>     That's not necessarily how games are designed, though; I know
> >> that with our engine, input is represented internally as an array
> >> of gamepads.  It lets us do things like feed a pad with a stack of
> >> pad values to do things like demos and "replays".
> >
> > Alright. The remaining reasons are still significant, IMHO: this is
> > the design pattern for Wayland input devices and even in general,
> > and the protocol needs to move less bytes when the pad_index is
> > effectively baked into the object id on the wire.
> 
>     The question is, is a gamepad an object, or is a *set* of gamepads
> an object?

Both, just like a wl_pointer can be one or more physical mice. Whether a
wl_pointer is backed by several mice, the clients have no way to know,
or separate events by the physical device.

The interfaces are abstract in that sense.

> >>     This is I think where there's a potential problem.  Gamepads
> >> live in a somewhat more chaotic world than mice and keyboards;
> >> wireless ones have much shorter battery lives, and players are
> >> used to being able to unplug and plug them while playing.  It's
> >> not uncommon for someone to (say) play for a bit with a gamepad
> >> they don't like (maybe it was on sale), unplug it, and plug in one
> >> they like better.  Or drop the gamepad that ran out of batteries
> >> in the charger and pull out another.
> >>
> >>     Players also expect to be able to add a gamepad part way
> >> through a game, at least for some games.
> >>
> >>     So, gamepads can appear and disappear during the game's
> >> runtime, and the game needs to know that is happening.  There also
> >> need to be some heuristics about which gamepad is what player (or
> >> seat).
> >
> > So you would rather handle all that in your game, than rely on the
> > display server to sort it out for you? The user would have to set up
> > each game, instead of just the display server. The display server
> > could also drive the player id indicators on some game controllers.
> 
>     I'd rather the display server sorted it out, honestly, I just
> wasn't sure how much policy people were comfortable with pushing into
> the display server.

I think we can put lots of policy in the server. A Wayland server is not
just a generic display server like X, but is actually tied to the GUI
paradigms, shell, and the desktop environment. In principle, every DE
will have its own server, and code re-use is punted as an
implementation detail. We prefer to communicate intent (set_fullscreen)
rather than primitive actions (set window size && position it to 0,0 &&
raise).

For example, a window manager with all its policies is just a component
inside a Wayland server. It's also intended to be user configurable,
like a modern DE.

> > I can easily imagine a game controller configuration GUI for a
> > display server, where you can register game controllers and assign
> > them to different seats, just like you would do for keyboards and
> > mice.
> 
>     I'd prefer something like that.  On the console side of things,
> this is a problem that actually usually gets thrown to the game to
> solve, and it's always a hassle.

Alright, cool.

> >>     I think all gamepad input should be routed to whatever has
> >> focus or whatever has grabbed input.  I don't see a scenario where
> >> it makes sense to route different gamepads separately unless
> >> you're doing multiuser multihead (which I assume is the point of
> >> the wl_seat abstraction).
> >
> > A wl_seat does not relate to any specific output. Each wl_seat on a
> > server simply shares all outputs with all other wl_seats.
> >
> > If you want to do separate sessions, that is each user has his own
> > desktop, own input devices, and own outputs, then you pretty much
> > run one display server for each user.
> >
> > wl_seats OTOH allow one to have several people collaborating on the
> > same session and desktop, or just one person who needs more than one
> > keyboard focus, for instance. This is one display server with
> > several wl_seats.
> >
> > wl_seat is not really a seat in the physical sense. It may be better
> > thought via input devices and input foci. One wl_seat has zero or
> > one wl_keyboard, wl_pointer, etc. If you have several physical
> > keyboards, they all act as one. To have two keyboards independent,
> > they are assinged to different wl_seats. Then each keyboard can be
> > typing into a different window at the same time.
> >
> > Focus is per wl_seat, and mostly per input device type. Keyboard and
> > pointer have their own foci, wl_touch does not have a focus at all
> > in the protocol.
> >
> > So for games with multiple local players on the same screen, wl_seat
> > would be just a player id.
> >
> > Does this clarify what I was talking about?
> 
>     Ok, that makes sense.  So, from the game point of view, if each
> gamepad lives in its own wl_seat, how does the game detect that new
> gamepads have arrived or gone away?  I assume there are wl_seat
> create/destroy events?

wl_seats are global objects in the protocol, and yes, we have events for
globals to come and go dynamically. The events are in the wl_registry
interface.

If just a gamepad goes away and later comes back, the wl_seat could
even stay around in between. There can also be seats without a gamepad,
so it is still the game's responsibility to decide which wl_seats it
takes as players.

Which reminds me: maybe we should add a name string event to wl_seat
interface? This way a game, if need be, can list the seats by name
given by the user, and the user can then pick which ones are actual
players. (It is a standard procedure to send initial state of an object
right after binding/creating it.) I imagine it might be useful for other
apps, too.

Unless it's enough to just pick the wl_seats that have a gamepad?

Hmm, is this actually any better than just handing all gamepads
individually without any wl_seats, and let the game sort sort them out?
How far can we assume that a wl_seat == a player, for *every*
existing wl_seat? And which player is which wl_seat?


Thanks,
pq