CONTROLLERDEVICEREMOVED, which increments on each unplug


Message-ID: <20141122060307.GA16371 at>
Content-Type: text/plain; charset=utf-8; format=flowed

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: 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.

The data structure would have to depend on what diversity of things
you wanted to support. For example, you could break a hypothetical
flight-sim throttle into a base unit with a few switches, and a
hand-hold with a hat/dpad, maybe a trigger, and a few buttons. Where
you wanted to stick the actual throttle axs itself would be an issue,

I think that the most “powerful” possibility would be to divide
devices into “signals” and “groups”:
Signals: Each button/axis/etc would be assigned a “signal id” in
integer form (with multiple e.g. usb-NES controllers presumably having
identical ids for the “A” button, just as an example), and querying
values/signal types/etc would happen by using a device id and a signal
id together.
Groups: Each “behavioral component” would be assigned a “group id” in
integer form (once again, identical groups on identical devices
usually == identical ids), with each “group id”/“device id” pair being
associated with a list of "signal id"s.

The full API would look something like this:
int SDL_GetNumDeviceControls( SDL_DeviceID id );
int SDL_GetInfoDeviceControl( SDL_DeviceID id, int control,
SDL_ControlData *dst );

int SDL_GetNumDeviceGroups( SDL_DeviceID id );
int SDL_GetNumDeviceGroupControls( SDL_DeviceID id, int group );
int SDL_GetIDDeviceGroupControl( SDL_DeviceID id, int group, int index );

What type EXACTLY SDL_DeviceID and SDL_ControlData would be, I don’t
know (though I would prefer SDL_ControlData to be a structure with a
caller-populated size value, to support unforeseen future extensions).
I do, however, think that this could probably go into an extension
library fairly easily, and personally I would want to see everything
from joysticks, to keyboards and mice, all rolled into the same system
(consider: some of the MMO gamer mice apparently export a keyboard
interface to provide extra buttons due to limitations in the USB mouse
HID spec… why not represent those buttons via the same interface as
the rest of the mouse buttons?).

Now, for a throttle you might not need to be able to express that two
groups of controls both share a control, but what about weird stuff
like the Namco NeGCon (I think there was an even weirder 6DOF one that
used a trackball or something for the joint, too)? I doubt that there
is any sensible rule of thumb for how to resolve multiple claims on a
control for something like that.

Your “types” would presumably be applied to control groups. You’d need
to do an enumerate cycle to find the particular controls that you
wanted (presumably THAT info would be in the SDL_ControlData
structure), but it should work fairly well, and it wouldn’t require
adding yet another input extension (beyond maybe some types or
something) in two years. It’s also a fairly simple API: five
functions, and in the worst case probably no more than three

For the *InfoDeviceControl function, maybe a skeleton implementation
something like this:

struct SDL_ControlData
size_t len;
float val;
struct SDL_ControlData2
SDL_ControlData cdat;
Uint32 type;

int SDL_GetInfoDeviceControl
( SDL_DeviceID id, int control, SDL_ControlData dst )
switch( dst->len )
( (SDL_ControlData2
)dst )->type = ???;
dst = &( ( (SDL_ControlData2*)dst )->cdat );
dst->val = ???;
return( -1 );
return( 0 );
}> Date: Fri, 21 Nov 2014 22:03:07 -0800

From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] CONTROLLERDEVICEREMOVED .which increments on each