Input and games.

[Pekka Paalanen]

On Sun, 5 May 2013 15:27:54 -0400
Todd Showalter <todd at electronjump.com> wrote:

> On Sun, May 5, 2013 at 12:55 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > 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.
> 
>     I don't think there's any problem in principle with the gamepad
> events being delivered to the same client that has keyboard focus.
> The only annoying thing is if (in a multiplayer game) someone can
> screw you by sending you a well-timed IM that pops up a window and
> steals focus, but honestly I think that's more an argument against
> focus stealing than it is for not attaching gamepad focus to keyboard
> focus.

Focus stealing indeed, there has been some discussion about that.

The problem is, that a wl_seat may not have a keyboard, hence it does
not have a keyboard focus. And if there are multiple wl_seats, one for
each player, as a user I don't want to individually assign each player's
focus to the game.

>     I don't see any reason why you couldn't have two (or N, for some
> reasonable N) games running at the same time, using the same gamepad,
> and only the program with focus sees gamepad events.  There are some
> tricky cases, if the game wants to have multiple windows with no
> containing root window, for example, but maybe that's one of those
> "well, don't do that, then" cases.

That shouldn't be a problem, since with the concept of focus, we have
input device events "enter" and "leave", which tell a client which
surface has the focus.

And this also affects the protocol design again. If we have the concept
of gamepad focus, we need the enter and leave events in some inteface.

>     Having given it some thought, I'd be inclined to be cautious about
> how much you consider the gamepad-with-builtin-keyboard case.  They
> really made those things to make MMOs viable on game consoles.  As far
> as I know, not a lot of people have them, and the main argument for
> them is on consoles which don't have native keyboards.  On a PC, the
> kinds of games that need keyboards are the kinds of games you tend to
> want access to the mouse.  That's not to say that nobody will ever use
> a gamepad keyboard in a game on Linux, but I'd argue it's on thin
> enough ground that I wouldn't let it drive the design considerations.

I could imagine the Wii pointer exposed as a wl_pointer with the
gamepad... hrm, that's another curious input device that does not fit
well in our categories: it needs a cursor image, but provides absolute
positions unlike a mouse, right?


Thanks,
pq