Input and games.

[Pekka Paalanen]

On Thu, 2 May 2013 19:28:41 +0100
Daniel Stone <daniel at fooishbar.org> wrote:

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

Right. Could we just say that each such non-aggregatable device must be
put into a wl_seat that does not already have such a device?
Or make that an implementors guideline rather than a hard requirement
in the protocol spec.

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

So... what's wrong in putting each keyboard into the wl_seat where it
belongs, along with the gamepad?

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

It would be left for the client to decide which gamepad it wants from
which wl_seat, right?

Do we want to force all clients to choose every non-aggregatable device
this way?

Essentially, that would mean that wl_seat are just for the traditional
keyboard & mouse (and touchscreen so far) association, and then
everything else would be left for each client to assign to different
wl_seats on their own. This seems strange. Why do we need a wl_seat
then, why not do the same with keyboards and mice?

Oh right, focus. You want to be able to control keyboard focus with a
pointer. Why is a gamepad focus different? Would all gamepads follow
the keyboard focus? If there are several wl_seats with kbd & ptr, which
keyboard focus do they follow? What if the same gamepad is left active
in more than one wl_seat? What if there is no keyboard or pointer, e.g.
you had only a touchscreen and two gamepads (say, IVI)?

And then replace every "gamepad" with "digitizer", and all other
non-aggregatable input devices, and also all raw input devices via
evdev fd passing. The fd passing I believe has similar problems: who
gets the events, which wl_seat do they follow.

This is a new situation, and so many open questions... I just continued
on the exitisting pattern.


Cheers,
pq