#2917 Saitek Pro rudder pedals not working on next branch

[ranguli]

Running the next branch (2020.04) on PopOS 22.04LTS.

The rudder pedals appear to be recognized correctly in the Input Devices window (which unfortunately has some really poor UX compared to the old input menu, but I'm assuming this is a developer-oriented version that's not in release builds for end-users), and the Axis value correctly changes from -1 to +1 with full left or right rudder input on the pedals. However, the actual /control/flight/rudder property is being capped between -1 and -0.99609, meaning the rudder is essentially locked at full input in one direction.

I've marked this as high priority only because the Saitek Pro rudder pedals are probably some of the most common out there, so its an issue that certainly would need to be addressed before the 2020.04 release.

[ranguli]

I've narrowed down the error to this commit https://sourceforge.net/p/flightgear/fgdata/ci/793dd0f7704b321b97a83c2c5bac933b1e3c25d8/. Deleting /Input/Event/Saitek/Pro Rudder Pedals.xml seems to solve the problem and things go back to the way they were.

This is my first time ever looking at input device configuration .xmls, so I don't have a solid understanding of whats going on here, so I can only guess to what's going on:

The presence of the <min-range> , <max-range>, <offset>, and <property-scale> and <factor> tags suggest we're taking an n-bit integer representing the current input value from an input device, and then scaling it to the range of another n-bit integer before passing it off to the sim.

If that is the case, there is no scaling or offset being done on the rudder pedal input themselves:

~~~
<event>
<desc>Rudder</desc>
<name>abs-z-rotate</name>
<min-range>0</min-range>
<max-range>511</max-range>
<binding>
property-scale
<property>/controls/flight/rudder</property>
</binding>
</event>
~~~

There is scaling done on the other inputs for the pedals like the toe brakes.

I don't know anything about what happens to these values after they're passed along, but I would assume that either a) the raw values are unacceptable to FlightGear or b) if an <event> object is missing a <property-scale> there is some kind of logic error.

@jsb1685 as the author of the commit any chance you would be able to help debug what is going on? My guess could be entirely off. It would be much appreciated.

Cheers,
Joshua

[Henning]

You found the USB HID config file for the Saitek pedals. Raw data for the rudder axis is between 0 (full left) and 511 (full right). It works on my system as it should.
Did you by chance deactivate some of the input systems? e.g. by using one or more of
--prop:bool:/sim/input/no-event-input=true
--prop:bool:/sim/input/no-joystick-input=true
--prop:bool:/sim/input/no-hid-input=true

[ranguli]

Hello,

The only arguments passed to FlightGear were --launcher, none of the input systems were disabled.

[ranguli]

[Roman Ludwicki]

Hi. I have the same issue.
A few days ago I noticed a problem with my “Saitek Pro Flight Rudder Pedals” controller in the next version. I always have the rudder tilted to the maximum left. In the “Joystick Configuration” window, I can see that everything is working properly, when I move the pedals, axis 2 responds in a range of values from -1 to 1, but the rudder still remains in the same position, maxed out to the left. Clicking the “Reset Configuration” and “Refresh Joysticks” buttons does not help.

The Input Devices window looks like this, in the “Joystick input” field I have listed:

• “Saitek Saitek Pro Flight Ridder Pedals”, (why double “Saitek Saitek”, I don't know?).
  in “USB HID input” I have.
• “Saitek Pro Flight Rudder Pedals (2)”.
  and in the “Linux Event input” field I have 2 items listed:
• “Saitek Pro Flight Rudder Pedals (0)”.
• “Saitek Pro Flight Rudder Pedals (1)”.

I don't know what this means, why is there so much of this, why are there some indexes 0, 1 and 2 in brackets?

In output log i notice one related info:

9.59 [ALRT]:input can't open InputDevice Saitek Saitek Pro Flight Rudder Pedals_0

Additional info: when I use the 0 and Enter keys or the mouse control the rudder moves correctly, it only jams when I move the Saitek pedals, so it's clearly the controller's fault. The aircraft doesn't matter, it happens on every one.

On FG version 2020.3.19 the problem does not occur.

[ranguli]

Roman, it sounds like we are experiencing the same issue.

I don't know what this means, why is there so much of this, why are there some indexes 0, 1 and 2 in brackets?

Yes, I agree, the graphical configuration of joysticks seems to have gotten more complicated and less user-friendly in the 2024. I'm sure that the new changes under the hood are beneficial and will be a great asset to FlightGear, but the way it's presented to the end-user right now is detrimental to user experience.

[Roman Ludwicki]

I have a workaround.
In my case, I need to disable event input by using the option:
--prop:bool:/sim/input/no-event-input=true
and rudder starts working as it should.

Why do we need the event input?

I can also disable hid input
--prop:bool:/sim/input/no-hid-input=true
because it doesn't do anything in my case, only the log info disappears:

9.59 [ALRT]:input can't open InputDevice Saitek Saitek Pro Flight Rudder Pedals_0

[Roman Ludwicki]

One more update from me. I checked how it works on Windows 11 and here I have no problems, rudder works fine. As far as I can see here the “Linux Event input” list is empty. So the problem seems to occur only on Linux, ranguli is using PopOS, I'm using Linux Mint 21.3

[ranguli]

Hi all,

I can happily report this issue appears to have been resolved now on the next branch. I can no longer reproduce the issue. @playerom are you still experiencing the issue on Linux with the latest build(s)?

Also for context, I don't need to use the workaround that Roman mentioned, it 'just works' now. I double checked the command-line options that the launcher is creating and it doesn't seem to be adding that automatically or anything.

[Roman Ludwicki]

I won't check at the moment, because build next on Linux doesn't work for me, I have compilation errors.

But from what I saw, the author of the changes added a commit where he simply disabled event-input for Linux, so it should work :)

https://sourceforge.net/p/flightgear/fgdata/ci/54fb978ccfb7db35d6aa3c6aa6be75d3f4826ebc/