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: