The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I was wondering if SDL 1.3 supported hot plugging
usb joysticks, so on a mac I grabbed r4410 from subversion
and tried this short program:

#include <stdio.h>
#include <SDL.h>
#include <assert.h>

int
main(int argc, char** argv) {
printf("So hot\n");
int res;

res = SDL_Init(SDL_INIT_JOYSTICK);
assert(res == 0);

while(1) {
printf("num joysticks = %i\n", SDL_NumJoysticks());
sleep(5);
}

return 0;
}

SDL_NumJoysticks() always reported the number of joysticks
observed at SDL_Init time, so would that be a no? SDL 1.3
does not support hot plug joysticks? Or do I need to reinit the
subsystem if I want to pick up joysticks plugged in after launch?

RF

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


Edgar

Rhythmic Fistman wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl8MmcACgkQolm4VNX3QTwhWwCgyLStbp0FphnLsMo6ICX3w6I+
srQAoJUGXl8pO0U4735atDoy7kWp6p71
=zuBR
-----END PGP SIGNATURE-----

On Sun, 25 Jan 2009, Edgar Simo wrote:


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.

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.

-Crystal

On Sunday 25 January 2009 03:29, Crystal Jacobs wrote:
On Linux when the device is plugged back in it will appear with the same bus
number (assuming the user plugs back into the same USB port), but will have a
different USB device number. The code would then have to check the device ID
(and possibly the serial number) to verify that it is the same physical unit.

I'm pretty sure it works the same way with Mac OS X, but I don't know (and
don't care) about Windows.

Jeff

On Sun, 25 Jan 2009, Jeff Post wrote:


In that case, on Linux, could one use epoll, and kevent on FreeBSD, to
watch for newly re-created devices in /dev? And on OSX,
IOServiceAddMatchingNotification()? As in:

http://developer.apple.com/documentation/DeviceDrivers/Conceptual/AccessingHardware/AH_Finding_Devices/chapter_4_section_2.html#//apple_ref/doc/uid/TP30000379/BABEACCJ

(libev for BSD/Linux maybe? Not that SDL needs more dependencies. I am
not terribly familiar with the various options for event handling on
Linux, but I imagine it's not necessary to use libev.)

I have no idea how this would be implemented on Windows, either.

-Crystal

On Sunday 25 January 2009 07:04, Crystal Jacobs wrote:
I use libusb. I don't know if it generates events as my application works fine
just by polling using usb_find_busses, usb_get_busses, and usb_find_devices.
But my app doesn't need to poll continuously as there are certain conditions
under which it expects the USB devices to change. I didn't spend time
learning any more about libusb than I needed for my application. You might
want to investigate it further.

Jeff

Not yet, but it is on the TODO list.

See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Just thought I would throw this out here, since sometimes this idea
pops into my head, but it seems a little crazy and unnecessary. Maybe
someone out there will have something interesting to say about it:

Sometimes I think about writing code which synthesizes false joypads /
mice / keyboards and synthesizes events for them. Maybe it gathers
data over a network or something. Yes, that's a good question, why
wouldn't I just inject my events at a different software layer? Why do
I have to do it at the SDL event queue?

Does anyone else know what I'm talking about?

--
http://codebad.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


There was some module to allow creation of character devices (linux)
from userspace. Look at the userspace xbox 360 driver for more details,
but it shouldn't be too hard to do at a "below SDL" level.

Userspace 360 driver link:
http://pingus.seul.org/~grumbel/xboxdrv/


Edgar

Donny Viszneki wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl8oCQACgkQolm4VNX3QTx67gCg58bASNH+poMVHZcKdKXHi4ZQ
+08An1i3/sYZEBSe4adx982LZjrVISrf
=x9PR
-----END PGP SIGNATURE-----

On Sun, Jan 25, 2009 at 12:23 PM, Edgar Simo <bobbens at gmail.com> wrote:

Forgive my ignorance, but could you explain what challenge is overcome
by this technique?

--
http://codebad.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


You wanted to generate fake joystick/keyboard events right? This is the
easiest way to make them work with any application on your linux box.
Without having to code anything into your SDL project to generate fake
SDL events. Maybe I don't really understand what you want to do.


Edgar

Donny Viszneki wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl8oqcACgkQolm4VNX3QTyVrwCg336RH0ErbBzOFXf65Ds260DH
Fc0An3mbdA3RMp4Tp7FRASaLBuBEVz7+
=gtMF
-----END PGP SIGNATURE-----

On Sun, Jan 25, 2009 at 12:34 PM, Edgar Simo <bobbens at gmail.com> wrote:

How does creating character devices add events to the SDL event queue?

The only difference between a "fake" event being where the code is
that generates the event? (Which may soon actually have an effect on
performance.)

In my case I don't want to create a character device which other
applications might accidentally think was a joypad that they might
want to use. I was probably being very silly, I can't think of a very
good reason to want to inject "fake" SDL events, but it did seem an
amusing idea.

--
http://codebad.com/

On Sun, Jan 25, 2009 at 11:08 AM, Jeff Post <j_post at pacbell.net> wrote:


libusb provides a way to get the list of file descriptors that should
be watched, so this could be integrated with a select()/epoll/etc run
loop (like that I'm working on, patch coming soon):

http://libusb.sourceforge.net/api-1.0/group__poll.html#gb1a72869a926552b27a6c667695df3a2

Thanks to Crystal for that link sent previously, I'll check and see if
I can make sure it can be integrated with what I do in my in-progress
patch. Seems it should be possible if we can watch Mach ports (on Mac
OS X only, of course!).

--
http://pphaneuf.livejournal.com/

On Sun, Jan 25, 2009 at 11:14 AM, Donny Viszneki
<donny.viszneki at gmail.com> wrote:

Oh yeah. Ever seen a dial box? Now you have an application that costs
10s of thousands of dollars (yes they exist) and it *requires* a
"specific" dial box. Now company X will buy 50 of your $500,000 dollar
workstations, but only if they can keep running that application
without that horribly expensive dial box.

You create a nice graphical application that pretends to be a dial box
and with a little tweaking of X server (custom X extension) and a very
special device driver you make that graphical dial box pretend to be a
physical device that provides the same sequence of bytes on a fake
serial port that the real dial box provides on a real serial port.
And, of course, it accept the same command strings as the real box but
displays the changes on the screen through the graphical dial box.

I got asked if we could fake the dial box in a sales support meeting
about 20 years ago. Didn't get any further than that. I once did have
to provide a fake X server. I.E. we built a version of XLib that
talked directly to the screen and the input devices. No server, damn
near no OS. Just DirectXLib. :-) Did it to port an X application to a
box that it was never designed for. Hrm, sounds a lot like SDL doesn't
it.

Good ideas are like spicy food, they just keep coming back.

Bob Pendleton




--

+ Bob Pendleton: writer and programmer
+ email: Bob at Pendleton.com
+ web: www.GameProgrammer.com
+ www.Wise2Food.com

+--------------------------------------+

[...]


Thanks for the considered response. Luckily, this Foobie's playing on
a mac, so he should be able to call
IOServiceAddMatchingNotification(kIOHIDDeviceKey) and then re-init the
joystick subsystem.

Portably speaking, I don't know if the SDL api would work with a
changing number of joysticks.

RF

On Mon, Jan 26, 2009 at 4:33 AM, Rhythmic Fistman <rfistman at gmail.com> wrote:

And joysticks that are potentially reordering themselves.

--
http://codebad.com/