Input and games.

[Todd Showalter]

On Thu, May 2, 2013 at 5:44 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 30 Apr 2013 09:14:48 -0400
> Todd Showalter <todd at electronjump.com> wrote:
>
>>     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!

    The day job is interfering a bit, but I'm hoping to be able to
start working on this shortly.

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

    Right.  From a game point of view, we don't want to do the
conflated-device thing; it makes some sense to have two mice
controlling a single pointer on a single device (the thinkpad nub
mouse + usb mouse case), but it never makes sense to have multiple
gamepads generating events for a single virtual gamepad.  The game
needs to be able to tell them apart.

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

    Ok, good.

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

    Fair enough.  So, I'll need to fork Weston if I want to build my
fever dream combo of Quicksilver and Sawfish, then.  :)

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

    Ok, so in principle the game just watches for wl_seats appearing
and disappearing, and checks to see if they have gamepads attached.

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

    This is the icky problem for whoever handles it.  If a gamepad
disappears and then appears again attached to a different usb port, or
if a gamepad disappears and a different pad appears at the port where
the old one was, is it the same wl_seat?

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

    That's why I was assuming originally that gamepads would all be
attached to a single wl_seat and come in with pad_index values.
However it winds up getting wrapped in protocol, what the game is
interested in (if it cares about more than one gamepad, which it may
not) is figuring out when those gamepads appear and disappear, how
they map to players, and what input each player is generating.

                                        Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.