Input and games.

[Pekka Paalanen]

On Mon, 29 Apr 2013 20:04:12 +0000 (UTC)
Rick Yorgason <rick at firefang.com> wrote:

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

I don't think this helps anything. Events are either swallowed by the
server, or sent to the client in focus. As long as the event is part of
the same wl_gamepad interface, having it separately makes no difference.

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

Then all those programs need to create the wl_gamepad object. Whether
that works or not, depends on how we design the input event
dispatching, i.e. the gamepad focus.

It might be more sensible to create another protocol extension for
this. If the server does not handle the home button, or if nothing
subscribed the home_interface, then it gets passed to the game as
usual. The whole purpose of home_interface would be to just notify
about the home button presses.

It's a similar case with volume control buttons. If you want them to
control master volume, the display server must intercept them and
either handle them itself, or pass then via a special interface to a
volume control applet. If you want them to control per-app volume by
keyboard focus, you might want to route these buttons to the application
as normal.

What an application could actually do when it receives a home button
press via the special path is an important question. Since Wayland does
not allow random clients to just jump in, you need to specifically
think how to enable a desired response. In that respect, having a third
party program handling the home button is very problematic, since you
probably want something to happen on screen.


Thanks,
pq