Troubleshooting input devices

Troubleshooting input devices will try to help you with input device issues, like with joysticks, yokes and keyboards.

Other than this page, consider visiting the main page for input devices, and the forum section on hardware, with its FAQs on joysticks.

Known issues

Checking the position of your controls

Often, when trying to find what's wrong with your controls, you'll need to be sure that the movements are correctly interpreted. For this, the Head-up display (HUD) will be very helpful, as it has indication of their position. Press h to enable the HUD and see its wiki page to learn how to interpret it.

USB Joystick Fails to Work

FlightGear is designed to recognize automatically any USB joystick that it is aware of (has a configuration on file for it). Configuration for USB joysticks is located in the Inputs folder. For example:

Input/Saitek/X45.xml

The name reported by the joystick through the hardware of your system must match the name specified in the configuration file. If the stick identifies itself as

Saitek Saitek X45 Flight Control Stick

but the configuration file specifies

Saitek X45 USB Flight Stick

FlightGear will fail to recognize it.

This happens with some frequency. It has been known for the same stick in a manufacturer's line to report different identifier strings. If you encounter a problem getting your usb stick to be recognized by FlightGear, it is helpful to first check to see

• a configuration file matching the name of your stick exists
• the configuration joystick name matches the name the stick actually reports to your computer

USB Joystick exhibits permanent offset / requires repeated recalibration

USB Joystick drivers should automatically zero and calibrate the joystick on plugin. Some examples of some types of joystick can be faulty where the fault is exhibited as an offset from the zero position when this process is completed. In Kubuntu this can be fixed for the session by use of the Joystick calibration tool under "Keyboard and Mouse" of "System Settings", or equivalent tools with other distributions, but the problem will recur.

In some cases this may be caused by improper connector seating or other loose connections within the joystick. This can sometimes be remedied by unscrewing the base or other case element to access the circuit board and then reseating the connectors. Also check for faulty solder joints and discrete components bent over onto the circuit board. Before attempting any repair unplug the device and remove any batteries.

Configuring CH Products Under Windows Vista

The CH Products Yoke and Pedals are among the most popular flight sim controls. FlightGear provides excellent configuration files for both the Yoke and Pedals manufactured by CH. Windows Vista recognizes and configures the USB versions of these products by default. However, it reports them as "Generic Controls." This creates an issue when FlightGear tries to assign the appropriate controller configuration.

To overcome this you need to edit your Joystick.xml (Filghtgear\Data\Joystick.xml) file to manually assign a configuration file for FlightGear to use.

Eg:

If you have the Yoke as MS-Windows Controller 0 and Pedals as Controller 1 then you include the following lines:

  <js n="0" include="Input/Joysticks/CH/pro-yoke-usb.xml"/>
  <js n="1" include="Input/Joysticks/CH/pro-pedals-usb.xml"/>

[Enter] does not work for rudder control

First of all: if [0] doesn't work, check if toggling num-lock solves the issue.

Open file $FG_ROOT/keyboard.xml with your preferred Editor. and search for those lines (it's close to the top, around line 40):

     ## uncomment this line to get keycode reports printed to the terminal window
     #setlistener("devices/status/keyboard/event", func(n) debug.dump(n.getValues()));

Read the first one and uncomment the second one. To uncomment it remove the leading "#".
Save the file and run FlightGear as usual but with the log-level set to "alarm" (no need to do anything if it wasn't used/changed before!).
When FlightGear is running press [Enter] and immediately after this, without doing anyting on the keyboard, click on FlightGears log window and you'll see something like this in the last two lines of the log:

{ key: 13, modifier: { meta: 0, shift: 0, alt: 0, super: 0, ctrl: 0, hyper: 0 }, pressed: 1 }
{ key: 13, modifier: { meta: 0, shift: 0, alt: 0, super: 0, ctrl: 0, hyper: 0 }, pressed: 0 }

The first line is for pressing the [Enter]-Key, the second for releasing it. Keep the first number, named "key", in this exaple shown as "13", in mind.

Open file $FG_ROOT/keyboard.xml again and search for "enter". You should find following:

<key n="10">
 <name>Enter</name>
 <desc>Move rudder right</desc>

Now replace the value of key n= with the one you had to keep in mind earlier. Save file and run FlightGear to test it.

If the [Enter] key doesn't work at all for some reason one solution would be to assign the key right hand next to (not the num-block-)[0], if it is not already assigned to something else. Procedure is the same as shown with the [Enter] key.

Last thing to do, in any case, disable the keycode reports by replacing the "#" which we removed earlier.

Controls returning to a particular position

Some laptops have an onboard gravity sensor, that might be detected by FlightGear as a joystick. You can set FlightGear to ignore this fake-joystick:

1. Get your accelerometer's name via the in-sim Help > Joystick Information dialog.
2. Add this name to your $FG_ROOT/Input/Joysticks/Accelerometers/accelerometers.xml file, enclosed by <name> and </name> tags..
3. Report your device name to #flightgear at irc.flightgear.org, or on the hardware support forum, so it can be included in the "official" accelerometer.xml file.