Request: Joystick unique identifiers

[tomva-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello all-

This general topic has been discussed on these forums before.

I did have a request for the Joystick API: every attached joystick should have a unique ID. The programming model should be that there are many uniquely identified joysticks, and a few will be repeatedly attached and detached throughout the lifetime of the program. So a user should be able to attach/detach joysticks at will, and it should be gracefully handled by SDL (events just show up when attached, and when not attached, the program can query SDL interfaces to see if the joystick is there or not).

At the moment, hotswapping isn't really supported. Programs can repeatedly shutdown and then re-initialize the joystick subsystem to try to work around this, but it is clunky and slow. And in any case, without unique IDs (probably the manufacturer's serial numbers) even that breaks down. For instance, if the user has identical USB adapters for their joysticks, they may plug in A, then B, then detach both, then plug in B again. How will the client program know which joystick was just plugged in?

I am already working on 2-3 other open source projects at the moment, so I can't get to this myself. Maybe someday I will. But if there are others who are working in the Joystick area I would love to see deep support for hotswapping and unique and reliable identification of joysticks. (by "deep support" I mean that the core of the joystick code must assume that joysticks are repeatedly being swapped in and out)

-Thomas

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

[Kenneth Bull]

2009/11/4 tomva <tomva@...>:
> I did have a request for the Joystick API: every attached joystick should
> have a unique ID. The programming model should be that there are many
> uniquely identified joysticks, and a few will be repeatedly attached and
> detached throughout the lifetime of the program. So a user should be able to
> attach/detach joysticks at will, and it should be gracefully handled by SDL
> (events just show up when attached, and when not attached, the program can
> query SDL interfaces to see if the joystick is there or not).
>
On Windows you can use the device path to uniquely identify each
device.  On Linux, you might get away with that, but if a mouse is
unplugged and a different mouse is plugged in, you may not be able to
tell them apart by path.

> At the moment, hotswapping isn't really supported. Programs can repeatedly
> shutdown and then re-initialize the joystick subsystem to try to work around
> this, but it is clunky and slow. And in any case, without unique IDs
> (probably the manufacturer's serial numbers) even that breaks down. For
> instance, if the user has identical USB adapters for their joysticks, they
> may plug in A, then B, then detach both, then plug in B again. How will the
> client program know which joystick was just plugged in?
>
You can use SDL_JoystickName to retrieve the name of the device.  If
you have two identical controllers you can't tell the difference, but
different products will have different names.

> I am already working on 2-3 other open source projects at the moment, so I
> can't get to this myself. Maybe someday I will. But if there are others who
> are working in the Joystick area I would love to see deep support for
> hotswapping and unique and reliable identification of joysticks. (by "deep
> support" I mean that the core of the joystick code must assume that
> joysticks are repeatedly being swapped in and out)
>
Joystick, mouse and keyboard support need a rewrite to support
hotplugging in any reasonable manner.  Most likely, the result would
not be compatible with existing programs (mouse IDs greater than the
number of attached mice, for example).  It still needs to be done
though.
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org