Exposed Joystick Name, Product ID and Manufacturer ID

[NoobsArePeople2]

Okay, it sounds like this is the current proposal for the new information:

class Joystick
{
public:
    struct Identification
    {
        Identification()
        {
            name = "No Joystick";
            manufacturerId = 0;
            productId = 0;
        }

        sf::String   name;                      ///< Name of the joystick
        unsigned int manufacturerId;            ///< Manufacturer identifier
        unsigned int productId;                 ///< Product identifier
    };

    static Identification getIdentification(unsigned int joystick);
};
 

The previously existing info (button count and axes) would remain where it is and sf::JoystickInfo would be renamed back to sf::JoystickCapabilities. I think this works nicely.

[Nexus]

That looks mostly good; it would be nice if the constructor were defined at the end of the .cpp file and the constructor initializer list were used, in order to be consistent with other SFML classes:

Joystick::Identification::Identification() :
name          ("No Joystick"),
manufacturerId(0),
productId     (0)
{
}

If there are no other objections, I will test the code on the weekend and give you further feedback. You said you already tested it, so the main things should work. But the more joysticks and operating systems we can investigate, the better.

So, if anybody is willing to participate in testing, that would be appreciated (especially for OS X or FreeBSD)!

[NoobsArePeople2]

I haven't implemented FreeBSD, when using FreeBSD the getName(), etc functions all return the defaults.  I wasn't able to get a KDE nor Gnome installed on FreeBSD, nor could I find any documentation on the usb api SFML is using. Is the FreeBSD version working? The code for it seemed spare and there isn't an official download on the SFML download page.

Agreed on the contructor/initialization list. If we're liking this API change I can make all the updates to the PR before the weekend (probably Friday evening). No sense testing what we've got if we're making a bunch of API changes now.

[NoobsArePeople2]

If there are no other objections, I will test the code on the weekend and give you further feedback. You said you already tested it, so the main things should work. But the more joysticks and operating systems we can investigate, the better.

I just pushed up a commit with the sf::Joystick::Identification change as discussed. Tested things out on the following:

• Windows 8 x64: 360 wired and wireless controllers
• Mac OS Lion (10.7): 360 wired
• Ubuntu 13.10 x64: 360 wired
• Linux Mint 16 x64: 360 wired
• Manjaro x64: 360 wired
• Fedora 20 x64: 360 wired

All the Linux distros are tested using VirtualBox with a Windows host OS. Everything seems to be working okay. Going to take some more time tomorrow to go over things and test out my other controllers.

BTW, I wrote this quick and dirty app for testing joysticks awhile back. Link.

[Nexus]

Thanks for everything so far! I'll get back to you after trying it out.

[NoobsArePeople2]

Did some more in-depth testing this morning.

Windows 8 x64

Compiled with Mingw GCC 4.8.1.

• Xbox 360 wired/wireless: both work great as expected since they are as close to an "official" gamepad as we're likely to get for Windows.
• Dual Shock 3: I'm using the Motioninjoy driver with Better DS3 for configuration. I've set the pad to use XInput meaning it shows up in the system as a wireless 360 pad. As far as getting the identification info and using the pad things work fine. I've found the driver to be a little buggy at times though -- random disconnects or switching from XInput to DirectInput mode.

Linux

All distros are 64 bit and tested via VirtualBox running from a Windows 8x64 host. I tested the following distros:

• Ubuntu 13.10
• Linux Mint 16
• Manjaro
• Fedora 20

• Xbox 360 wired: Works great.
• Xbox 360 wireless: Mostly works but we don't get the product or manufactuer IDs. Nor do the triggers register. More on this below.

There are two drivers for the Xbox 360 pad on Linux: xpad and xboxdrv. Xpad is shipped with the kernal and is the defacto "official" Linux driver. Xboxdrv is a third party driver that must be installed manually (and part of the installation is disabling xpad entirely). So it's an either-or situation with these drivers.

I wanted to give xboxdrv a try because Linux was not recognizing my wireless 360 pad. So I did some Googling and found that people were also using xboxdrv. Now, my wireless pad may not be recognized due to the VM situation but it appears that xpad doesn't recognize it while xboxdrv does.

When testing the pad with jstest-gtk in Ubuntu all the sticks, triggers and buttons work as expected. Similarly, when using the lsusb -v command in Terminal I can see the product and manufacturer IDs. However, when running in my gamepad testing app neither the product nor manufacturer ID can be read. Both the triggers are ignored as well.

For the product and manufacturer IDs I think the problem is that I xboxdrv needs to be run as a daemon (docs) but I unable to do this even when I sudo to root. This bears some more investigation but I really don't feel like dealing with manually configuring Linux drivers today so I'll come back to it tomorrow or next week Possibly the issue with the triggers is related.

I'd be great if someone can test wireless 360 pads on a native Linux install (non-VM) so we can see if xpad will recognize them.

Here's the link to the reference I used for setting up xboxdrv: link.

Mac OS Lion (10.7)

SFML compiled with Clang and C++11 enabled.

• Xbox 360 wired/wireless: I'm using the Tattieboggle 0.08 driver (tried using newer versions with no such luck, maybe they are for newer OSX versions?). Both controllers worked fine.
• Dual Shock 3: Connected via Bluetooth using the built-in OSX driver (I believe this has been included since Snow Leopard). Controller works great with the exception that L2 and R2 only register as buttons not as the analog triggers they are. Hopefully this is addressed in newer OSX versions.
• Wiimote (no attachements), with nunchuck, with Classic Controller: Connected via Bluetooth using the WJoy 0.7.1 driver. All the buttons and analog sticks work as expected. The driver doesn't appear to report values from the motion sensors in the Wiimote.

[Nexus]

Thanks a lot for the detailed investigation! I think you shouldn't waste too much time with driver-specific issues (unless you enjoy it ). It's already very nice if we can add this feature and it works with the standard drivers in the most cases -- it's still possible to improve the implementation over time, especially when we get feedback from more people. But currently you're doing all the work alone.

I can test on a native Linux Ubuntu 12.04, but I do not own any wireless joysticks. If anybody is willing to help, don't hesitate!

[Nexus]

I've tested two gamepads and one joystick for Windows 7, Windows 8 and Ubuntu 12.04. All of them are native operating systems.

The product and manufacturer IDs were recognized consistently on all systems. The names showed slight differences:

• Windows 7
  ColourRumblePad
  WingMan RumblePad
  USB Game Controllers (there seems to be only generic information about this one; Saitek PC Joystick)
  
  
• Windows 8
  Saitek P580 RumblePad (perfect)
  WingManblePad (not sure what went wrong here, maybe driver problem, the joystick is ancient -- but it's also stated so elsewhere in Windows)
  USB Game Controllers
  
  
• Ubuntu 12.04
  Logitech Inc. WingMan RumblePad (perfect)
  JessTech ColourRumblePad (wrong manufacturer: Saitek is correct)
  MegaWorld USB Game Controllers (again Saitek)

Is it usual that Linux also includes the vendor (or at least tries to) in the description, while Windows often doesn't?

But apart from those deviations, for which SFML probably can't do anything, it works quite well

One thing I also noticed, but which is not part of this issue, is that Linux also recognizes the accelerometer in my laptop as a fourth joystick.

[NoobsArePeople2]

From my testing the names for devices seem to be completely arbitrary on every OS. It's possible that Linux either adds the vendor name or it's convention for driver authors to do so. I suspect most controller drivers for Windows are written by the manufacturer while Linux versions are added by the community which may also have something to do with differing naming schemes for the same device.

In any case it's probably best to rely on the vendor and manufacturer IDs to accurately identify controllers in code and use the name to identify the controller to the user.

I also noticed that I get extra joysticks on Linux -- one of them is the VirtualBox mouse integration device and another is a VirtualBox USB tablet (which I assume has to do with my drawing tablet). In both cases these devices appear as joysticks in /dev/input/js so in that since SFML is picking them up as expected. Perhaps the Linux implementation should be extended to further test connected joysticks to ensure they are actually joysticks.

JessTech ColourRumblePad (wrong manufacturer: Saitek is correct)

Does the manufacturer ID correspond with Saitek? Here's a list of USB IDs.

[NoobsArePeople2]

I think you shouldn't waste too much time with driver-specific issues (unless you enjoy it ).

A sick, twisted part of me kinda wants to dig into this but I think I'll pass for now if you're not worried about it. A little further investigation shows that xpad works well for most people so it's not like we leave a ton of folks out in the cold by not fully supporting non-standard drivers.

[Nexus]

Perhaps the Linux implementation should be extended to further test connected joysticks to ensure they are actually joysticks.

Yep. In my example, the accelerometer simply had no buttons, so that would also be a possibility to detect it. This check also seems to be used elsewhere. But let's keep that for later.

Does the manufacturer ID correspond with Saitek? Here's a list of USB IDs.

No. According to that list, it's indeed "Jess Technology Co., Ltd" (0f30). But Windows uses the same manufacturer ID and assigns it to Saitek. It looks like others have had this assignment, too.

I'm wondering whether vendorId would be a better name than manufacturerId. It seems to be a bit more often used (e.g. in Android API, but also discussions across the Internet). On the other hand, "manufacturer" might be more expressive.

I've also added a few remarks to the pull request. What do you think, are there important things left for a first version?

[NoobsArePeople2]

Yep. In my example, the accelerometer simply had no buttons, so that would also be a possibility to detect it. This check also seems to be used elsewhere. But let's keep that for later.

Sounds good.

No. According to that list, it's indeed "Jess Technology Co., Ltd" (0f30). But Windows uses the same manufacturer ID and assigns it to Saitek. It looks like others have had this assignment, too.

Hmmm...Googling reveals a company called Jess Tech that does make gamepads. I wonder if they are a re-badge of Saitek pads for certain markets?

I'm wondering whether vendorId would be a better name than manufacturerId. It seems to be a bit more often used (e.g. in Android API, but also discussions across the Internet). On the other hand, "manufacturer" might be more expressive.

I've been going back and forth on this as "manufacturer" is rather a pain to type (especially compared with "vendor") and, as you mentioned, "vendor" tends to be used more often. Honestly, I went with "manufacturer" because I implemented the Windows version first and that's how the value is referred to in the JOYCAPS structure. I could go either way, though I'm inclined toward changing it to vendor for the reasons above.

I've also added a few remarks to the pull request.

I saw that, looking through them in detail now but they seem straightforward.

What do you think, are there important things left for a first version?

I think we could ship this feature as-is and I'd be an immediately useful improvement to SFML. The Linux driver issue discussed earlier in the thread is something I'd like to get worked out but I don't think it's needed for a v1 release.

[Laurent]

"Vendor ID" is indeed the standard word for USB devices.

[Nexus]

The pull request has been merged. Thanks again for your great efforts.

[NoobsArePeople2]

The pull request has been merged. Thanks again for your great efforts.

Excellent! Glad to help.