Input and games.

[Rick Yorgason]

Todd Showalter <todd at ...> writes:
>     I think all gamepad input should be routed to whatever has focus
> or whatever has grabbed input.

...and then...

> > I don't think we need a separate event for this, just the normal button
> > event is enough. If the display server wants to eat the event, it can
> > do so in any case. Or was there some other reason for this?
> 
>     Mostly to logically separate the home button from the others.
> It's not available on all gamepads.  The gamepads that do have it are
> gamepads for hardware platforms (wii, ps3, xbox 360), and the button's
> purpose is "interrupt the game and bring up the OS".  Pressing it gets
> you access to meta things like system settings, gamepad settings, and
> GUI buttons to do things like quit the game, which is useful in
> single-screen environments where the game is running full-screen.
> 
>     Splitting it off isn't essential.

One reason you might want to split the system button into a separate message
is because you might not want it to follow normal focus rules. For instance,
I can imagine Steam's Big Picture using it, but since Steam isn't a
compositor, it wouldn't be able to swallow the button press.

A more generic solution would allow apps to steal all input from individual
buttons, but that's probably overkill. The simplest solution is just to make
it so the system button event is broadcast to all programs, even those
without focus.

Also, I sort of doubt this changes anything, but I just found out that the
OUYA does something strange with home button to compensate for the lack of a
start button: it sends a 'start button' message if you just tap the home
button, but sends a 'system button' message if you hold it. (In the dev kits
you can also double-tap the button, since it seems that the holding
behaviour required a firmware update.)

-Rick-