CONTROLLERDEVICEREMOVED .which increments on each unplug

In SDL2 2.0.3 on OSX, I’m using the attached pysdl2-cffi Python code
to keep track of attached game controllers. I’m plugging in and
removing a single XBox controller to test.

When the code gets CONTROLLERDEVICEADDED, event.cdevice.which is
always 0, but when it gets CONTROLLERDEVICEREMOVED,
event.cdevice.which is 0, then 1, then 2, and so on.

Since ‘which’ on remove does not match ‘which’ on added, there is no
property on the controller objects that I can just match up with the
’removed’ events. Instead, when I get a ‘removed’ event I iterate over
all my controller objects and discard the ones that are not still
attached.

Is this a bug, or have I misunderstood the ‘event.cdevice.which’ value
on CONTROLLERDEVICEREMOVED?

Thanks,

Daniel

Is this a bug, or have I misunderstood the ‘event.cdevice.which’ value
on CONTROLLERDEVICEREMOVED?

We should make this more clear at the API level for SDL 2.1, but "which"
means something different for each of those events:

 Sint32 which;       /**< The joystick device index for the ADDED 

event, instance id for the REMOVED or REMAPPED event */

The idea is when it’s added, you can do
SDL_GameControllerOpen(which)…and several other things that operate on
unopened joystick indexes. This is a number that might get recycled if
we add a stick after one has been removed, to keep
SDL_NumJoysticks()-sized arrays reasonable).

On removal, though, this will be an instance id. This number is unique
and increments on each new joystick the system sees. You can get this
for a controller with:

 myInstance = 

SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(myController));

(maybe for 2.1, we’ll get rid of joystick indexes and use instance ids
for everything.)

–ryan.

Is this a bug, or have I misunderstood the ‘event.cdevice.which’ value
on CONTROLLERDEVICEREMOVED?

We should make this more clear at the API level for SDL 2.1, but "which"
means something different for each of those events:

Sint32 which;       /**< The joystick device index for the ADDED

event, instance id for the REMOVED or REMAPPED event */

The idea is when it’s added, you can do
SDL_GameControllerOpen(which)…and several other things that operate on
unopened joystick indexes. This is a number that might get recycled if we
add a stick after one has been removed, to keep SDL_NumJoysticks()-sized
arrays reasonable).

On removal, though, this will be an instance id. This number is unique
and increments on each new joystick the system sees. You can get this for a
controller with:

myInstance =

SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(myController));

(maybe for 2.1, we’ll get rid of joystick indexes and use instance ids
for everything.)

No wonder. I was trying to ignore the joystick api, and wondered why I
could not find game controller get instance id.On Oct 7, 2014 11:40 AM, “Ryan C. Gordon” wrote:

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ryan,

If you lose the device indices, you would lose the enumeration loop
and events will become essentially required. Which IMO is fine, as
all major platforms SDL supports are event-based, most including
events an application MUST respond to or be regarded as fundamentally
broken.

I think one of the goals of the ability for events to be optional in
the first place was to allow for extra-lean static builds of SDL on
embedded platforms such as game consoles maybe? In practice, any
such thing SDL still supports has gone to having mandatory event
structures like everything else. :slight_smile:

I would not mind seeing a little break with backwards compatibility
even with the event interface in 2.1 a little bit if it meant that
you no longer needed to keep a laundry list of open controllers.

I also wouldn’t mind seeing some API changes in how joysticks and
game controllers rrelate and interoperate a bit to reflect a little
better how these things are used?but that kind of requires that I say
"Arrrgh! Thread hijacked!"

Of course at the time I wanted to discuss that, 2.0 was fresh and
new, the controller DB was only available burned-in and was sparse,
the only real effective configurator tool for end-users to generate
mappings was Steam, and a number of popular retro controllers simply
couldn’t be mapped. Then I got totally distracted by 10^6 different
higher-priority things forcing hobby interests out of the foreground
and other people began dealing with some of the above problems
without me. Haven’t been tracking closely enough to see where things
stand now. So with that in mind, I’ll discus some personal 2.1 goals
for joystick/controller management:----------------

Controller TYPE!

Reflecting the way people actually use these controller devices both
on consoles and on PCs (which aren’t always the same), and giving
devs some hints so that when a controller appears, they have some
idea what to do with it. I imagine mappings would include a major
class (which may affect SDL’s handling) and a delineation hint that
SDL will almost certainly never care about. Might be an unsigned 32
bit value intended to be used as a bit field?

Major classes I envision:

  • Basic “modern” controller (non-Nintendo!) Pretty much the status
    quo now, though perhaps with the added benefit of knowing that
    mappings providing this WILL have certain controls. Two analog
    sticks, shoulder buttons, two triggers (may be digital), DPad, four
    face buttons, and at least one control button (start/pause/menu).
    Hints might include that the triggers are analog and that additional
    features beyond the basic definition exist.

Hints for the above: Sony has included accelerometers, now a
touchpad, and on PS2 controllers, analog buttons (though I don’t know
if any PC interface exposes that feature?) Microsoft has chatpads
and sound devices. Apple makes all controls optionally analog,
including the DPad for the greatest WTF in gaming? Easily 99% of
games would never care about the hint, unless there’s something
specific they need.

  • Retro controllers and arcade sticks. Why? The modern controllers
    do a fine job standing in for the SNES controller unless you have a
    Microsoft XBox 360 controller, anyway. :wink: The thing is, some of us
    like the feel of the older controllers. (FWIW, I recommend Buffalo’s
    SNES controller which is on Amazon here: http://goo.gl/K7rJ90 They
    also do an original Famicom style controller, but sadly no analogues
    to the Genesis/Saturn, N64, or GameCube? The cheap USB copies CAN be
    made good enough if you’re willing to mod them?)

Anyway, here the hints become actually more useful. Some useful
hints I see are Arcade/fighter (Genesis/Saturn/SF2 arrangement),
old-school (DPad, only one button), NES, SNES, Genesis 3 button, N64,
GameCube, and some odd birds on a modern system like paddles (two
players, traditionally “one” analog stick and two fire buttons, but
we could use X axis of left and right stick if we decide to?), and
old-school analog (the two paddles as a single analog joystick with
two fire buttons?)

  • Dance mats(?), perhaps so they can be ignored when looking for
    normal controllers?

  • Band instruments. Definitely so they can be ignored when looking
    for normal controllers. Notably, there are multiple franchises with
    slightly different mappings. We could sort that in mappings I
    suppose? Obvious hint is the type of instrument.

  • Modern Nintendo. May be totally outside of the realm of the game
    controller API. I dunno, I don’t own a Wii, shockingly enough. I
    figure the Wii U iPad wannabe is off the table for now, but if we can
    make the rest work, why not?

That just leaves the stuff that’s not really a gamecontroller model
device in any way (flight control stuff for example) and stuff that
is, but has more than we can express with the current API.

I’d be interested in discussing a way to query features of things
like that and figuring out how to access them. But I don’t have much
to offer about how to go about it now.

Sorry for the novel,

Joseph

On Tue, Oct 07, 2014 at 11:40:30AM -0400, Ryan C. Gordon wrote:

Is this a bug, or have I misunderstood the ‘event.cdevice.which’ value
on CONTROLLERDEVICEREMOVED?

We should make this more clear at the API level for SDL 2.1, but
"which" means something different for each of those events:

Sint32 which; /**< The joystick device index for the ADDED
event, instance id for the REMOVED or REMAPPED event */

The idea is when it’s added, you can do
SDL_GameControllerOpen(which)…and several other things that operate
on unopened joystick indexes. This is a number that might get recycled
if we add a stick after one has been removed, to keep
SDL_NumJoysticks()-sized arrays reasonable).

On removal, though, this will be an instance id. This number is unique
and increments on each new joystick the system sees. You can get this
for a controller with:

myInstance =
SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(myController));

(maybe for 2.1, we’ll get rid of joystick indexes and use instance ids
for everything.)

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org