Gamepad focus model (Re: Input and games.)

[Peter Hutterer]

On Mon, May 13, 2013 at 09:14:25AM +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 09:12:03 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote:
> > > On Thu, 9 May 2013 16:44:09 +1000
> > > Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > > 
> > > > On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote:
> > > > [...]
> > > > > I had a private chat with Daniel, and we came to an understanding,
> > > > > which I try to describe below. The interface names below are more like
> > > > > placeholders for now.
> > > > > 
> > > > > Into wl_seat, we should add a capability bit for gamepad. When the bit
> > > > > is set, a client can send wl_seat::get_gamepad_manager request, which
> > > > > creates a new wl_gamepad_manager object. (Do we actually need a
> > > > > capability bit?)
> > > > > 
> > > > > A wl_gamepad_manager will send an event for each physical gamepad (as
> > > > > it dynamically appears, if hotplugged later) associated with this
> > > > > particular wl_seat, creating a wl_gamepad object for each.
> > > > > 
> > > > > A wl_gamepad object will send an event about the player id as the first
> > > > > thing, and also if it later changes.
> > > > 
> > > > do you expect the player ID to be exposed on the protocol?
> > > > what does it contain and who manages the association?
> > > > is it related to any physical ID of the gamepad, and if not, can such ID be
> > > > provided (if the device supports it)?
> > > 
> > > I imagined the player ID to be sent explicitly in the protocol, with
> > > its very own event. The server would manage the association between
> > > physical devices and the player ID, according to built-in heuristics
> > > and user preferences.
> > > 
> > > E.g. if one goes from 0 gamepads to 1 gamepad, it will always be player
> > > 1; or maybe take the first player slot that does not have a gamepad,
> > > unless we identify the device as the same that was recently unplugged
> > > in which case take the player slot that it used to have. Or something,
> > > with user preferences, and some UI to fix the association in the rare
> > > case when the heuristics choose wrong.
> > > 
> > > Recognizing a gamepad could be done via physical identification, if one
> > > is available, or by usb port/hub, or whatever platform specific way.
> > > The clients would not have to care, they would only work with unique
> > > player IDs, which are integers created in sequence starting from 1 (or
> > > 0).
> > 
> > first - I agree with player ID being assigned to a gamepad for the simple
> > reason of giving all clients a baseline.
> > 
> > I think that phys information should be exposed in some way. use-case here
> > is a specific controller that is always owned by the same human player. the
> > game could then associate this automatically with the player.
> > this could be a later addition to the protocol though, because right now I
> > have no idea how to do this sensibly.
> 
> Wouldn't that be better configured in the server, rather than in every
> game?

yes. but whether or not the device is actually associated with a fixed
player is likely client-specific (as in: only few clients will make use of
that I suspect)

> But yeah, I don't even have any idea what should be exposed as physical
> info.
> 
> > > Using integers starting from 1 makes it trivial for the server to
> > > update the player ID display on the gamepads, if they have one.
> > > 
> > > The server could also implement a global UI to reassing gamepads. For
> > > instance, press the famous home button for 5 secs on any gamepad, get
> > > some gamepad controllable GUI to reassing them, or maybe just a request
> > > to press the home button again on each gamepad in sequence.
> > 
> > this UI could also handle the seat assignment, see below.
> > 
> > > Doing all this client side would mean we need to find a way to
> > > communicate all the device and platform specific hints for the gamepad
> > > assignment heuristics somehow, and each client instance would have its
> > > own gamepad assignments.
> > > 
> > > > is the player ID not better represented through a wl_seat? - if you're
> > > > playing a full-screen game, both seats can safely have the same focus,
> > > > otherwise, players can play games independently.
> > > > plus, if both players have a separate seat, they can use their keyboard
> > > > independently for data entry.
> > > 
> > > Those were exactly my thoughts in the beginning, however during the way
> > > long email thread, I got convinced otherwise for now. There are a few
> > > issues that come mind:
> > > - how to know, when one seat should follow the keyboard(?) focus of
> > >   another seat?
> > 
> > I wonder when this is necessary. unless I'm misunderstanding something this
> > should only be of concern when both users want to change games (or otherwise
> > between clients)?
> 
> I would imagine, that two players each with own gamepads is a more
> common case when playing the same game on split-screen or alike, than
> playing two different games. Therefore, when the game is started, the
> display server would ideally somehow know to assing both gamepad foci
> to the game window.
> 
> The basic assumption with seats is that each is independent, but the
> server is of course free to assign foci as it chooses. This is just a
> server implementation detail.
> 
> But I guess it does not really matter how it is on the protocol level,
> there would need to be a "focus group" configuration in the server
> anyway; either by protocol allowing several gamepad in one wl_seat, or
> a purely server detail by focus groups containing wl_seats.
> 
> I think this is not a protocol question as much as a server
> implementation consideration, so... *shrug*.

right. the other argument here is that you have N wl_seats with N-1 of them
only containing a gamepad device anyway, you can group their focus into one
and handle them as one. that again is a server implementation but games only
need to worry about one gamepad per seat and can use the seat as player
abstraction.

[who knows, in the future you could then attach identification to the
wl_seat, making it possible for clients to autoconfigure not just based on
who's logged in but who's actually controlling a device. future stuff, I
admit]

the other thing that made me thing about your approach:
with the gamepad_manager, you've got an extra layer in the tree for gamepads
that pointers/keyboards don't have. that's not a bad thing and focus
handling is easier this way, but now you could also look at pointers and
keyboards and see if that extra layer is useful for those two. And I think
it would be - e.g. wacom devices share their focus with the pointer, but
also have their device-specific stuff that clients may need.

so maybe something shared/generic is going to be useful here too - unless
gamepads are so specific they must be different (or should be different on
the protocol, generic abstraction isn't always the best thing).

> > > - a client still needs to map seats into players; how? does it need an
> > >   UI to fix it in case a user is not happy with the result?
> > 
> > well, tbh if you're planning for multiple seats at some point you'll need a
> > UI to handle it anyway. whether this is for ptr/kbd seats or gamepads, it
> > comes down to the same. but even with the proposal above you still need some
> > UI anyway.
> 
> Yeah, but my question is, is it enough to have a UI in the server, or
> does every game need one, too? Or do games need one in any case for
> other reasons, so it's not a really an issue?

I honestly don't know, Todd could probably comment on this better than me.
 
> > also, afaict this is what some game consoles have, e.g. the Wii associates
> > your controller with your Me.
> 
> What is "Me"?

oh, right. Wii Me is the little avatar you can configure and make your
look-alike. When you play a gain, you then tend to associate your controller
with your avatar. in some games (e.g. Wii Sports) the avatar is the one
in the actual game.

> I get the feeling there might be some more complex use case behind what
> you wrote. Is it perhaps players storing/associating their online
> player ID with their personal gamepad or something?

let's say I have a Wii with a black and a white controller and black is
always mine, white is always my partner's controller. likewise, the avatars
are always the same, but I still have to set it up after every startup.

from a user's perspective I have a strong association with a physical
device, mapped into a virtual presense and I'd like for this to be
automatic.

Cheers,
   Peter