Gamepad focus model (Re: Input and games.)

[David Herrmann]

Hi

On Mon, May 13, 2013 at 8:14 AM, Pekka Paalanen <ppaalanen at gmail.com> 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?
>
> But yeah, I don't even have any idea what should be exposed as physical
> info.

That is why the kernel provides "PHYS" and "UNIQ" fields for every
input device (they might be empty if not implemented, but at least
they're supposed to be there..). "PHYS" provides the physical location
for the device. "UNIQ" provides a unique identification.

So UNIQ can be used to track a single session. It is guaranteed to be
never reused during a single boot. So unplug+replug generates a new
ID.

PHYS can be used to track devices based on their physical "location".
For USB devices it's the bus-connection cpu->pci...->usb...->iface,
for Bluetooth devices it's the BDAddr, and so on.. This can be easily
used to connect a "player" to a controller.

Last but not least, many devices provide small EEPROMs that can be
used to store UUIDs for identification. However, these aren't exposed
in any generic way by the kernel, yet.

So no reason to worry about this. The kernel already provides enough
information.
Cheers
David