Testing your adapter and controllers

Contents:

Introduction

The intent of this page is to show how to test if an adapter is working properly at the operating system level.

For instance, if your controller does not work in a game, it does not necessarily mean that something is wrong with the adapter. It could also be (and often is) a configuration problem with the game or the emulator. Many games and emulators need to be told to use a joystick, and also to be told which one!

How can you tell? By testing the adapter and controller outside the target game or emulator using a known to work tool. If it works there, it is a game/emulator configuration issue. But if it does not work, it's either the adapter or the controller.

Testing on Windows

About Direct Input and Xinput

There are now two different systems a game developer can use to support joysticks in their game. The first one is known as Direct Input and has existed for over 20 years. Our adapters implement the USB HID standard which is widely supported (works on Linux, Mac, PS3, Android...) and also functions perfectly well with Direct Input.

The other input system game developers can choose to use is called Xinput. Basically, this is a newer API designed for specifically for Xbox 360 controllers. By using it, game developers know in advance the controller layout, i.e. how many buttons, where they are located, etc. Because Xbox 360 controllers have a fixed design.

This makes things easier for developers as they do not need to implement the features required to let you, the end user, remap buttons and axes to make the game usable with your favorite (non Xbox) controller. In other words, they just design for a one-size-fits-all controller and assume that you will comply and use an Xbox controller.

This is a problem, because the Xinput drivers do not support anything but Xbox 360 controllers (or products faking one). As a result of the increasing adoption of Xinput, a lot of excellent joysticks, racing wheels and adapters are not usable.

If your adapter and controller works fine using the Windows built-in game controller test (see next section) but does not work in the game you want to play, check if your game supports Direct Input. If it does not, you will have to use an Xbox 360 controller emulator such as x360ce.

Built-in controller test

Windows has a built-in game controller test. The Game Controllers window show a list of connected game controllers. Our USB adapters should show up in this list. Adapters with multiple ports will show multiple times in the list.



Selecting a game controller and clicking on the Properties button opens a joystick test window. You can test buttons and analog axes there to test if your controller is working properly.



If none of the buttons light up when you press buttons on your joystick, it could be a problem with the adapter as much as with the joystick. To rule out the possibilty of a defective joystick, test it on the original system if possible. (eg: If you are using a N64 to USB adapter, test your N64 controller on the original console).

If the controller is good, please contact technical support at support@raphnet-tech.com.

How to open Game Controllers?

Game Controllers used to be an icon in Control Panel, but in more recent versions of Windows finding it has become difficult. Here is how it is accessed in different Windows versions.

Windows 7

Step 1
Under Windows 7, first go to Control Panel and open Devices and Printers.. There should be an icon similar to the following somewhere:


Step 2
Right-click on the icon and select Game Controller settings.

Windows 10

Under Windows 10, the easiest way to open Game Controller settings is to type Joy.cpl in the search box next to the start button.



As you type, a match should be found for joy.cpl, Control panel item.



Simply click on it to open the Game Controllers window.

Testing on Linux

Confirming that the adapter is detected

When you connect an adapter, a few lines should appear in the kernel logs. Run dmesg or sudo dmesg and look at the last few lines for messages about a new USB device. For instance:
	new full-speed USB device number 15 using xhci_hcd
	New USB device found, idVendor=289b, idProduct=0038
	New USB device strings: Mfr=1, Product=2, SerialNumber=3
	Product: GC/N64 to USB v3.5
	Manufacturer: raphnet technologies
	SerialNumber: 101581
	input: raphnet technologies GC/N64 to USB v3.5 as ...
	...

Confirming that the adapter is exposed as a joystick device

Next you can look in the /proc/bus/input/devices for a matching entry. For instance:
	I: Bus=0003 Vendor=289b Product=0038 Version=0101
	N: Name="raphnet technologies GC/N64 to USB v3.5"
	P: Phys=usb-0000:00:14.0-14/input0
	S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14:1.0/0003:289B:0038.000D/input/input25
	U: Uniq=101581
	H: Handlers=event18 js0
	...
We can see above that the joystick has been allocated to js0. If you have several game controllers, the number will be higher. But if you only have one, it will usually be 0.

Testing with jstest

Under Debian (and derived distros) the package joystick provides a simple command-line joystick test tool named jstest.

Type jstest followed by the path to the joystick device. Example: 
	jstest /dev/input/js0
This will display joystick information and a list of values and button states that update as you manipulate the controller. (Note: The "Driver version" displayed by this tool is not the adapter firmware version. Do not pay attention to it.)


Testing with jstest-gtk

There is a graphical alternative to jstest called jstest-gtk: