-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Not supported in SDL 1.3. Not really sure how one would get around to
implementing it. I suppose the OS gives you some event or something?
Might be tricky to handle especially if you handle removing joysticks
also. The closest you can get to hot plugging would be to quit the
joystick subsystem and start it up again. That should work.
I’ll give my thoughts. First, I’ll ignore engineering aspects, and start
with a user interface story, starring our hero, Foobie the Gamer.
Foobie has a USB gamepad, which he plugs into one of the USB slots on the
front of his computer, for convenience. Unfortunately, it doesn’t really
stay in too well, and he occasionally bumps it out of the slot, and has to
put it back in.
From Foobie’s perspective, it should stop working when he knocks it out,
then start working again seamlessly when he plugs it back in. The worst
behavior for Foobie is requiring him to restart the game to get the pad
working again.
Besides these two options of “instant recognition”, and “have to quit and
restart”, a compromise could be made, to re-recognize gamepads without
restarting, but without doing so instantly. What sort of user experience
could this give Foobie? Will Foobie have to go into a menu, and pick a
menu item (such as “configure controls”) to get his pad working again?
Obviously, Foobie doesn’t want to have to do something like this, so it’s
a compromise for the sake of engineering requirements. Foobie wants the
ideal of instant recognition. But possibly better than having to go to
a menu, but worse than instant recognition, is delayed recognition. That
is, (perhaps very infrequent?) polling to check for new devices.
So, I see the following options:
* Handle this outside of SDL. For example, on Linux, using udev, to
have a persistent device across reconnections. This is probably a
bad solution, because Foobie is unlikely to have any idea how to do
such things. But, I do not know enough about system level support
for hot plugging to rule this out entirely.
* Event-based system, for instant recognition. I am not sure what
event systems are available, but again this is probably possible
at least on Linux. Also, this would integrate neatly into SDL's
existing event system. Ideal for Foobie, most efficient if it is
possible at the code level.
* Polling system, for delayed recognition. Almost as good as the
event-based system, from Foobie's perspective. Not as efficient,
but it shouldn't matter if the polling rate is low enough.
* Manual system. When Foobie goes to the configure controls menu,
the joypad subsystem is restarted, allowing him to reconnect the
gamepad without quitting. Less ideal, but easy to code.
* No system. Foobie hates this option, because he has to restart
his game all the time just because his USB port is crappy. If
he has to restart often enough, he might give up on the game
entirely. Least ideal for Foobie, easiest to code (no code).
The manual system can be in place at all times. An event-based system
could be implemented on platforms where it is relatively easy, assuming
such platforms exist! Then it could fall back to infrequent polling,
on systems where events are not available.
The polling and manual systems can be done without changes to SDL. The
event system probably requires changes to SDL. Polling even infrequently
could be inefficient enough to cause problems–I do not know.
Those are my thoughts.
-CrystalOn Sun, 25 Jan 2009, Edgar Simo wrote:
Did it to port an X application to a