Input and games.

[Pekka Paalanen]

On Tue, 30 Apr 2013 08:30:52 -0400
Todd Showalter <todd at electronjump.com> wrote:

> On 2013-04-30, at 3:29 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > 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.
> 
>     Perhaps this is a place for window manager functionality; if
> there is a separate home button message, we could allow a window to
> request to filter home button messages for another window.  So the
> hypothetical steam behaviour would be to request the home button
> events for any games it spawns.

Hello Todd,

unfortunately that is not how Wayland works at all. All clients are
isolated from the start, regardless how they are spawned. The idea
might be ok, but concepts and protocol design will be very different.

>     The advantage of the separate event in that case would be
> isolating the home button event, since I presume that nobody wants
> the security nightmare of arbitrary event filtering. The home button
> is a system meta event, so it's reasonable to have other processes
> watching it.
> 
>     I suppose it could be a broadcast event...

As far as I understand, what you want is what I described with the
home_interface, with the exception that there is no filtering based on
the currently focused client. The home_interface is just something an
unrelated client could subscribe to, and then it would get the home
button events.

The third party program handling the home button is a really problematic
case, and this still does not solve the question of what the client
receiving the home button event can actually do. Normally Wayland does
not allow clients to e.g. randomly raise themselves to top, not to
mention do anything to other client's windows, since they cannot even
reference anything from another client. Getting the event is useless,
if you cannot react.

Could we instead design a behaviour for the home button, which the
display server (which is also the window manager) would implement
itself, and which would also satisfy the Steam use case?

For example: the home button minimizes the currently focused fullscreen
window. Or, maybe it brings up the task switcher, if the task switcher
can be controlled by a gamepad. With the task switcher, the user could
select the Steam client, or another concurrent game, or...

I just believe, that sending "the home button was pressed" to all
clients as a "system meta event" is not right. Instead, the server
would intercept it, and send specific events to clients' windows, like
un-fullscreen, un-maximize, minimize, raise, lower, go to sleep, etc.
that all depend on the current shell (i.e. a desktop vs. a game console
GUI vs. a phone vs. a TV vs. ...).

If we solve this in the server, we don't have to note it in the gamepad
protocol at all. In fact, I think we can just postpone this problem,
since the wl_gamepad should be irrelevant to how a home button is
handled. wl_gamepad can perfectly well relay the home button events to
the game, anyway. The question is when and if that happens, and that
does not need to be written down in the specification.

Doesn't really help that I've never used Steam, nor know what Big
Picture is. But I do have a PS3 at home! :-)


Thanks,
pq