Methods for Disabling Joystick Reading in Linux
One problem that people have had with AntiMicroX in the past is when a game has bad controller support. In some cases, the game will allow you to disable controller support in the game so you can use AntiMicroX as a form of controller support. In other cases, there are games that will force controller support to be enabled if the game detects any joystick devices on your system. When a game forces controller support to be enabled, it can be a hassle, if not impossible, to use AntiMicroX to fix controller support in a game. However, there are a few ways to get around the problem of games having bad controller support depending on the situation. I will talk about a few methods that I have found on Linux to temporarily disable controller support in a game. Different methods work better under certain situations.
One game that I run under Wine that has caused many problems regarding bad controller support is DmC Devil May Cry. The controls within the game work fine although manual mapping is required. However, the menus are unusable. When you try to navigate a menu, the cursor goes all over the place even when you don't touch the controller so you cannot land on the proper menu item.
This problem is annoying enough to make me not want to use the built-in controller support. However, the game has no way for you to disable controller support. It forces controller support to be enabled if it finds any controllers connected under Wine.
Luckily, there is an option in Wine to disable controller probing. Under PlayOnLinux, you must open a command prompt for the virtual drive that is associated with your game. In PlayOnLinux, you would go to Configure -> Drive -> Wine and click the Command prompt button; in a terminal, you would typically run the program wineconsole. A new command prompt will then launch through Wine. From there, you run the program control. A new window will appear and you will click the Game Controllers option. From here, you can tell Wine to not probe the selected joystick devices.
Many older Linux games do not support controller hotplugging. If those games do not detect a controller when first launched then controller support will be disabled. Luckily, antimicrox supports hotplugging and automatically loading the last open profile so there is a simple workaround for this case. Once simple workaround that can be used with older games is to not have the controller plugged in when you start a game.
Make sure to have antimicrox launched and the desired profile loaded before unplugging the controller. After unplugging the controller, launch the game and let it get to the title screen. At that point, plug the controller back into your system. antimicrox will detect the controller and reload the last open profile for that controller. At that point, antimicrox should be usable for controller support.
For any SDL 2 application that takes advantage of the Game Controller API, there is a way to force gamepad support to be temporarily disabled. The method that can be used is to submit a blank game controller mapping string to the game. One game that I know of that requires this type of workaround is Duke Nukem 3D: Megaton Edition.
You will have to use an environmental variable in order for the game to see the mapping string. Under Linux, you can prefix the game command with the mapping string variable and the game will use it. Under Windows, you will have to run the set command before launching the game. Here is an example of a command that can be used to do this.
SDL_GAMECONTROLLERCONFIG="030000005e0400008e02000014010000,X360 Controller,platform:Linux" <command>
With a blank mapping string in place, the game will not detect any axis or button events from the game controller. This will allow you to then use antimicrox for controller support.
The process is a bit different when trying to do this within Steam on Windows. You have to specify the launch options for the game within Steam (Properties > General > Set Launch Options) and have the game launch from cmd.exe so that the environmental variable is in the same session as the game. Otherwise, the game will not see the mapping string and it will revert to using a mapping string included in SDL. The change is temporary so you can delete the custom launch options in order to get game controller support back.
"C:\Windows\System32\cmd.exe" /C "set SDL_GAMECONTROLLERCONFIG=xinput,X360 Controller,platform:Windows & %command%"
One program that I had heard about before but never used previously is a program called SDLHack. It is a program for SDL 1.2 applications that will allow you to minimize a fullscreen application without having to create an extra X session. It acts as a library wrapper that modifies the behavior of SDL 1.2 and the library wrapper is loaded using LD_PRELOAD. SDLHack also provides a means to disable joystick support in SDL 1.2. You would run the sdlhack script with the -d flag to disable joystick support in SDL 1.2. The URL for the program is http://www.jspenguin.org/software/sdlhack/.
sdlhack -d supertux2
One method that can be used to keep an application from reading a game controller is to disable read access for the corresponding device file under /dev/input. Firstly, launch antimicrox and make sure that the application can detect your controller. If the controller is detected and can read events from the gamepad then you will want to find the corresponding device file for the gamepad. You will have to change the permissions on the device before launching a game so that it will not be able to use the controller. You can run less /proc/bus/input/devices to find the controller device file or look at the files listed under /dev/input/by-id. Once the proper device file is found, change the permissions on the device so that your normal user does not have access to read the controller; this should not affect already open applications that have access to the controller.
$ sudo chmod 000 /dev/input/by-id/usb-©Microsoft_Corporation_Controller_03C20DE-event-joystick
Once you are done with a game and want to have proper access to the device file again, you can give your user read permissions again and newly launched applications should be able to detect the controller again. Depending on the udev rules set on your system, you could also unplug and replug your controller into your system and the proper file permissions should be restored.
You can take this one step further by allowing your main user to disable gamepad devices without needing to use sudo. This would be useful for making launch scripts to use in Steam. A udev rule will need to be added so that event*, and optionally js*, devices will be owned by your normal user so that the user can change the permissions of those devices as needed. The following example shows how to give the steam user in SteamOS permission to be able to perform a chmod without needing to use sudo.
KERNEL=="event*", NAME=="input/%k", MODE="660", OWNER="steam", GROUP="input"
KERNEL=="js*", NAME=="input/%k", MODE="660", OWNER="steam", GROUP="input"
This is the more invasive way of disabling joystick support for applications that read from joystick devices directly. This will require that you create a new user on your system that will not have access to any joystick devices; I will not delve into how to create users here. The new user that you create will be the user which will run any games in which you would like to force joystick support to be disabled. You will still need to be able to read the joystick devices for the user that will be running AntiMicroX.
You will need to find the joystick devices that you would like to disable in the /dev/input, and possibly /dev, directory. One way to find the proper device files is to check the contents of the /proc/bus/input/devices file to see the devices connected to your system. You will then have to find the ones that are joysticks and take note of the Handlers line. This will give you the last part of the file that you will have to change the permissions for. Here is an example of the output for my Xbox 360 controller.
$ less /proc/bus/input/devices
I: Bus=0003 Vendor=045e Product=028e Version=0114
N: Name="Microsoft X-Box 360 pad"
P: Phys=usb-0000:00:12.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:12.0/usb3/3-1/3-1:1.0/input/input23
U: Uniq=
H: Handlers=event11 js1
B: PROP=0
B: EV=20000b
B: KEY=7cdb000000000000 0 0 0 0
B: ABS=3003f
B: FF=107030000 0
You can then run chmod or chgrp on the joystick devices to disable those devices from being readable by the new user. Take note that this change will no longer be in affect when you reboot your system. A udev rule could help make the change permanent if you would like that. Here is an example that will make joystick devices belong to the games group.
$ cat /etc/udev/rules.d/99-custom.rules
# Set joystick devices to be owned by games group
KERNEL=="js*", SUBSYSTEM=="input", MODE="660", GROUP="games"
# Set force-feedback devices to be owned by games group
KERNEL=="event*", SUBSYSTEM=="input", MODE="660", GROUP="games"
Taken from http://forums.gentoo.org/viewtopic-t-953776-start-0.html
Based on the example above, the user running AntiMicroX will have to be a member of the games group and the user running the game must not be a part of that group.
To start with, you would launch AntiMicroX as you normally would. You would then launch the game as the new user by running su in a terminal before launching the game. If all goes well, controller support will be disabled in the game so you can rely on AntiMicroX to provide controller support.
su <user>
supertux2