Input and games.

Todd Showalter todd at electronjump.com
Sun May 5 12:27:54 PDT 2013


On Sun, May 5, 2013 at 12:55 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> In a wl_seat, we have one kbd focus, and one pointer focus. These
> two are unrelated, except sometimes some pointer action may change
> the kbd focus. Most of the time, they have no relation.

    As a total aside, OSX has this and it drives me nuts.  Scrollwheel
focus follows the pointer, keyboard focus doesn't.  In practise what
that means is that whenever I'm on OSX I wind up closing the wrong
thing.  Example:

- running an irc client and firefox
- colleague sends an url, I click on it
- firefox brings up the url, I mouse over to it and scroll through
with the scroll wheel
- I'm done with the link, clover-w to close the tab, and it closes my
IRC session instead, because keyboard focus never left the irc window

    I've had to use OSX for a couple of years now because of some iOS
projects we've been working on, and this still bites me at least once
a day.  It's *completely* counterintuitive GUI behaviour.

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

    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.

    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.

                                      Todd.

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


More information about the wayland-devel mailing list