Testing your adapter and controllers

Contents:

• Introduction
• Testing on Windows
  • About Direct Input and Xinput
  • Built-in controller test (Game Controllers / Joy.cpl)
  • Opening « Game Controllers » on Windows 7
  • Opening « Game Controllers » on Windows 10
  • joy.cpl errors (Game Controller Error, Duplicate device)
• Testing on Linux
  • Confirming that the adapter is detected
  • Joystick device
  • Testing with jstest
  • Testing with jstest-gtk
  • Event device
  • Testing with evtest
  • Access permissions

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.

Opening joy.cpl under 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.

Opening joy.cpl under Windows 10/11

Under Windows 10/11, the easiest way to open Game Controller settings is to type Joy.cpl in the start menu.



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



Simply click on it to open the Game Controllers window.

Known issues involving joy.cpl

1.Error when clicking on properties

From time to time, users report that even though the adapter works fine (it is detected by games, the buttons work, etc) they get an error when clicking Properties in joy.cpl.



The error reads:

Your game controller is not connected correctly. Please verify that it is plugged into your computer.

This message is probably a generic error message from the old days of 15 pin PC joysticks. It is quite misleading in this case:

1. Windows has no idea that this is an adapter, and Windows has no way of knowing if you connected a controller to the adapter or not. So no need to check if your controller is connected to the adapter properly. Normally, the Properties dialog opens just fine, regardless of whether you connected an adapter to the adapter or not. So this is not the problem.
2. No need to verify the USB connection to your computer either. If the USB cable was not plugged into your computer, the adapter would not appear at all in the list when opening joy.cpl! Again, not a very helpful suggestion.

So what does it mean? We don't know! Clearly Windows or joy.cpl is unhappy about something, but does not provide enough information for us to fix the issue.

There are three workarounds we know of:

1. Open the raphnet adapter manager and select the adapter. Joy.cpl will stop showing this error for as long as the adapter manager is running.
2. Just ignore this. The adapter works fine and should be usable in games, but when you need to test your controller buttons with joy.cpl, you can use the workaround above.
3. Use USBDeview (see next section) to force Windows to completely forget what it knows about the adapter, so next time you connect it, joy.cpl works again. (that is, until until Windows/joy.cpl becomes unhappy again)

2.Device appearing twice

We hear about an issue sometimes where even though the user has only one adapter connected, it shows twice in joy.cpl.
Some users report that it causes issues in some games too. (controller continuously connecting and disconnecting in Retroarch for instance)

Here is a screenshot showing what this looks like:



We know the issue is not that the adapter has become defective, since according to what we heard everything is normal when using the same adapter on a different computer. We do not know under what conditions this issue appears, and as we have never been able to reproduce this on any of our test systems to properly investigate, we do not have a perfect solution.

Some users reported that when the raphnet adapter manager is running and the adapter is selected, Joy.cpl and games then shows only one device, so leaving the adapter manager could help.

Otherwise, we know of one additional workaround: Removing the device completely, so that next time you connect it Windows sees it as a new device. Note that doing this using the device manager does not work. Some information seems to be retained, so the device is not really "forgotten" by Windows. This works well when done using a tool called USB USBDeview.

Just select devices with vendor ID 289b (our ID) one by one and click the trash icon in the toolbar (or select Uninstall Selected Device from the File menu).


Be very careful to **only** uninstall devices with vendor ID 289b, or some things may stop working! For the record, we are not responsible if you break your computer. Do this at your own risk.

After completing this process, disconnect and reconnect the adapter and things should work again, until the unknown conditions which cause the issue are met again... (please get in touch if you find a way to reliably cause this issue which works every time!)

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:

Confirming that the adapter is exposed as an event device

Similarly to how one can confirm that the adapter is exposed as a joystick device, one can determine which event device corresponds to the adapter by examiming the content of /proc/bus/input/devices for a matching entry. For instance:

	I: Bus=0003 Vendor=289b Product=0080 Version=0101
	N: Name="raphnet technologies 1-player WUSBMote v2.2"
	P: Phys=usb-0000:00:14.0-5/input0
	S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:289B:0080.09A2/input/input4074
	U: Uniq=431094
	H: Handlers=event24 js0
	...

Unlike joystick devices however, event devices are more generic (eg: buttons, mice and keyboard are also event devices) so on a typical system, you can expect a lot more than just one. In the above example, the adapter is assigned to event24.

Testing with evtest

Under Debian (and derived distros) the package evtest provides a simple command-line event device test tool named evtest.

When you run evtest, a list of available devices is displayed:

$ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event24:     raphnet technologies 1-player WUSBMote v2.2
Select the device event number [0-24]:

Type the number of the device (in this example, 24) and press ENTER.

You may also pass the path the evtest directly:

	evtest /dev/input/event24

Once evtest is running, as you manipulate the controller, events for each change of state (button press/release, value of analog axis changing, etc) will be displayed.

Note the warning message displayed by evtest when not running as root. If it does not work using a regular user, try again as root. If it then works, then your user does not have the required permissions to access the device.

Access permissions under linux

If evtest or jstest emits an error message when you try using a /dev/jsX or /dev/input/eventX device, but when you try as root (sudo /dev/input/jsX, etc) it works, then the user you are logged as does not have the required access permissions.

As a reference, below we will examine what things look like on a properly configured system where jstest and evtest both work fine as a regular user.

Standard unix permissions can be displayed using ls -l:

$ ls -l /dev/input/event24
crw-rw----+ 1 root input 13, 88 May  2 10:39 /dev/input/event24

$ ls -l /dev/input/js0
crw-rw-r--+ 1 root input 13, 0 May  2 10:39 /dev/input/js0

Above, it appears that event24 and js0 are accesible in read/write mode, for the owner (root) and the group (input).

We can see that the current user does not belong to the input group using the id command:

$ id
uid=1000(demo) gid=1000(demo) groups=1000(demo),24(cdrom),25(floppy),29(audio),30(dip),44(video)...

Yet, the user is able to access the device... Notice the + sign at end of crw-rw-r--+? This indicates that there are ACL (access control list) configured for the device. Under debian (and derivative), the 'acl' package provides a tool called getfacl, which can display detailed access permissions for a device.

$ getfacl /dev/input/event24
getfacl: Removing leading '/' from absolute path names
# file: dev/input/event24
# owner: root
# group: input
user::rw-
user:demo:rw-
group::rw-
mask::rw-
other::---

Above, we see that the user demo is explicitely granted read/write permissions for this device. This is why evtest and jstest works fine on this system. This seems to happen out of the box on this test Debian system when logged-in and running X. This may not be always the case depending on your configuration and distro.

A quick fix would be to add your user to the input group, but this could be a security risk. Your user probably should not be in the input group, as your user (and all programs run by that user) would then gain access to ALL input devices. For instance, a malicious program could then easily log your key strokes by opening the keyboard event device directly. Perhaps in some environnements this could be tolerated, but we do not recommend blindly adding your user to the input group. (nor would we recommend running everything as root!)

Another quick fix is to change the permissions on the device. (For instance sudo chmod 666 /dev/input/js0, which grants access to all users of the system) but due to the dynamic nature of USB devices, you will need to do this everything the adapter reconnects or when you reboot).

Please consult your distro documentation or forums on the proper way to grant your user access to a specific device.