Input and games.

[Daniel Stone]

Hi,

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

There's one crucial difference though, and one that's going to come up
when we address graphics tablets / digitisers too.  wl_pointer works
as a single interface because no matter how many mice are present, you
can aggregate them together and come up with a sensible result: they
all move the sprite to one location.  wl_touch fudges around this by
essentially asserting that not only will you generally only have one
direct touchscreen, but it provides for multiple touches, so you can
pretend one touch each on multiple screens, are multiple touches on a
single screen.

The gamepad interaction doesn't have this luxury, and neither do
tablets.  I don't think splitting them out to separate seats is the
right idea though: what if (incoming stupid hypothetical alert) you
had four people on a single system, each with their own keyboards and
gamepads.  Kind of like consoles are today, really.  Ideally, you'd
want an association between the keyboards and gamepads, which would be
impossible if every gamepad had one separate wl_seat whose sole job
was to nest it.

I think it'd be better to, instead of wl_seat::get_gamepad returning a
single new_id wl_gamepad, as wl_pointer/etc do it today, have
wl_seat::get_gamepads, which would send one wl_seat::gamepad event
with a new_id wl_gamepad, for every gamepad which was there or
subsequently added.  That way we keep the seat association, but can
still deal with every gamepad individually.

Cheers,
Daniel