On Mon, 29 Apr 2013 20:04:12 +0000 (UTC) Rick Yorgason <r...@firefang.com> wrote:
> Todd Showalter <todd@...> 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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
