Hallo zusammen,
nachdem ich einige Zeit mit der Fehlersuche bei Rudder Pedalen verbracht habe, die unter Linux funktionierten, aber von X-Plane 12 nicht erkannt wurden, habe ich schließlich die Ursache und eine dauerhafte Lösung gefunden.
Ich stelle die einzelnen Schritte hier ein, weil dieses Problem auch andere Rudder Pedale betreffen kann – insbesondere Geräte mit Achsen, aber ohne Tasten.
In meinem Fall handelt es sich um Turtle Beach VelocityOne Rudder Pedale, die folgende Vorgehensweise ist jedoch bewusst allgemein gehalten.
Fehlerbild
Die Pedale:
sind angeschlossen und werden von Linux erkannt
zeigen in Joystick-Testprogrammen alle Achsen korrekt an
erscheinen nicht in den Joystick-Einstellungen von X-Plane, wenn X-Plane normal gestartet wird
können verfügbar werden, wenn Anwendungen als root ausgeführt werden
Wenn die Pedale von Linux überhaupt nicht erkannt werden, handelt es sich wahrscheinlich um ein anderes Problem.
0. Prüfen, ob Linux die Pedale erkennt
Ein praktisches grafisches Werkzeug dafür ist jstest-gtk.
Unter Fedora:
</> Bash
sudo dnf install jstest-gtk
Starte:
</> Bash
jstest-gtk
Prüft, ob die Rudder-Achse und die beiden Toe-Brake-Achsen reagieren, wenn ihr die Pedale bewegt.
Wenn sie reagieren, ist die Hardware grundsätzlich für Linux sichtbar und ihr könnt mit den folgenden Schritten weitermachen.
1. Das richtige Input-Event finden
Falls nötig, evtest installieren:
</> Bash
sudo dnf install evtest
Danach ausführen:
</> Bash
sudo evtest
Wählt eure Rudder Pedale aus der Liste aus.
Ihr solltet bei einem Gerät wie diesem landen:
/dev/input/event23
Deine Event-Nummer wird ggf. eine andere sein. Sie kann sich außerdem nach dem erneuten Anschließen von Geräten oder nach einem Neustart ändern.
2. Prüfen, ob die Achsen funktionieren
Zum Beispiel:
</> Bash
sudo evtest /dev/input/event23
Bewegt Rudder und Toe Brakes.
Du solltest EV_ABS-Events und sich ändernde Werte sehen.
Wenn das funktioniert, empfängt Linux selbst Daten von den Pedalen.
3. Zugriff OHNE sudo testen
Beende evtest und führe anschließend genau denselben Befehl als normaler Benutzer aus:
</> Bash
evtest /dev/input/event23
Wenn dabei Folgendes erscheint:
Permission denied
habt ihr wahrscheinlich die Ursache gefunden.
X-Plane läuft normalerweise ebenfalls mit den Berechtigungen eures Benutzerkontos und kann daher kein Gerät lesen, auf das euer Benutzer keinen Zugriff hat.
4. Optionaler Diagnosetest
Um zu prüfen, ob die Berechtigungen tatsächlich das Problem sind, könnt ihr das betreffende Event-Gerät vorübergehend les- und schreibbar machen:
</> Bash
sudo chmod 0666 /dev/input/event23
Jetzt erneut ausführen:
</> Bash
evtest /dev/input/event23
ohne sudo.
Wenn das jetzt funktioniert, startet X-Plane normal und prüft, ob die Pedale erscheinen.
Wichtig!
Dies ist nur ein Diagnosetest, nicht die dauerhafte Lösung.
Verwende chmod 0666 für deine Eingabegeräte nicht als dauerhaften Workaround. Die Berechtigungen werden nach dem erneuten Anschließen des Geräts oder nach einem Neustart ohnehin normalerweise zurückgesetzt.
5. USB Vendor ID und Product ID ermitteln
Ausführen:
</> Bash
lsusb
Sucht nach euren Rudder Pedalen.
Bei meinen Turtle Beach VelocityOne Rudder lauten die relevanten IDs:
Vendor ID: 10f5
Product ID: 7012
In der folgenden udev-Regel musst du die IDs durch die Werte deines eigenen Geräts ersetzen.
6. Gerätespezifische udev-Regel erstellen
Eine neue Regel erstellen:
</> Bash
sudo nano /etc/udev/rules.d/70-rudder-pedals.rules
Folgendes einfügen:
SUBSYSTEM=="input", ATTRS{idVendor}=="YOUR_VENDOR_ID", ATTRS{idProduct}=="YOUR_PRODUCT_ID", ENV{ID_INPUT_JOYSTICK}="1", TAG+="uaccess"
Replace YOUR_VENDOR_ID and YOUR_PRODUCT_ID with the IDs from lsusb.
Für die Turtle Beach VelocityOne Rudder (10f5:7012) funktioniert bei mir folgende Regel:
SUBSYSTEM=="input", ATTRS{idVendor}=="10f5", ATTRS{idProduct}=="7012", ENV{ID_INPUT_JOYSTICK}="1", TAG+="uaccess"
Datei speichern und den Editor beenden.
7. udev-Regeln neu laden
Ausführen:
</> Bash
sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=input
Danach die Rudder Pedale abziehen, einige Sekunden warten und wieder anschließen.
8. Event-Gerät erneut ermitteln
Da Event-Nummern nicht dauerhaft fest sind, erneut ausführen:
</> Bash
sudo evtest
Führe den Befehl erneut aus und prüfe, welches /dev/input/eventXX jetzt zu den Pedalen gehört.
9. Der wichtige Test: evtest OHNE sudo
Führe jetzt aus:
</> Bash
evtest /dev/input/eventXX
erneut als normaler Benutzer.
Wenn du jetzt die Rudder-/Toe-Brake-Events ohne sudo sehen kannst, funktioniert die udev-Regel wie vorgesehen.
Das war in meinem Fall der entscheidende Test.
10. X-Plane normal starten
Startet X-Plane mit eurem normalen Benutzerkonto.
Starte X-Plane nicht mit sudo/root-Rechten.
Die Rudder Pedale sollten jetzt hier erscheinen:
Einstellungen -> Joystick
Kalibriert das Gerät und weist die Achsen zu.
In meinem Fall:
Axis 0 → Left toe brake
Axis 1 → Right toe brake
Axis 2 → Yaw
Die tatsächlichen Achsnummern können bei anderen Geräten natürlich abweichen.
11. Doppelte Achszuweisungen prüfen
Wenn ihr zuvor die Twist-Achse eines Joysticks für die Rudder-Steuerung verwendet habt, kann X-Plane warnen, dass mehrere Achsen Yaw zugewiesen sind.
Entfernt bzw. deaktiviert die alte Yaw-Zuweisung oder deaktiviert die Twist-Achse des Joysticks, falls die Hardware diese Möglichkeit bietet.
12. Was Ihr nicht tun solltet
Folgendes würde ich nicht als dauerhafte Lösung verwenden:
X-Plane nicht nur deshalb als root/sudo ausführen, damit die Pedale funktionieren.
Do not permanently give unrestricted permissions to all /dev/input devices.
Nicht sofort virtuelle Joysticks, Remapper oder uinput-Workarounds einsetzen, bevor geprüft wurde, ob es sich lediglich um ein Linux-Berechtigungs-/Klassifizierungsproblem des Geräts handelt.
Eine gerätespezifische udev-Regel beschränkt die Lösung auf die tatsächlich betroffene Hardware.
Warum passiert das?
Das scheint kein X-Plane-spezifisches Hardwareproblem zu sein.
Linux-Eingabegeräte benötigen die entsprechenden Berechtigungen, damit Anwendungen, die als normaler Benutzer ausgeführt werden, darauf zugreifen können. Rudder Pedale können dabei ein Sonderfall sein, da einige von ihnen nur Achsen und keine Tasten besitzen. Deshalb werden sie möglicherweise nicht wie ein herkömmlicher Joystick klassifiziert bzw. behandelt.
Die oben verwendete udev-Regel kennzeichnet das Gerät ausdrücklich als Joystick:
ENV{ID_INPUT_JOYSTICK}="1"
und gewährt dem angemeldeten Benutzer Zugriff über:
TAG+="uaccess"
Laminar Research hat ebenfalls Probleme mit Linux-Joystick-/Input-Berechtigungen dokumentiert und empfiehlt, diese über udev zu lösen, statt X-Plane als root auszuführen.
Getestete Konfiguration
Diese Lösung wurde erfolgreich getestet mit:
OS: Fedora Linux 44 (Cinnamon, X11)
Simulator: X-Plane 12.4.3-r2 (build 124311)
Hardware: Turtle Beach VelocityOne Rudder
USB ID: 10f5:7012
Functions: Rudder/Yaw + Left Toe Brake + Right Toe Brake
Die Pedale wurden erfolgreich geprüft mit:
jstest-gtk
evtest
X-Plane 12
und anschließend bei einem tatsächlichen Flug in X-Plane getestet.
Mögliche Relevanz für MSFS unter Linux / Steam Proton
Da das zugrunde liegende Problem die Klassifizierung und Berechtigungen von Linux-Eingabegeräten betrifft und nicht eine X-Plane-spezifische Konfiguration, könnte derselbe Ansatz auch bei Rudder Pedalen relevant sein, die in Microsoft Flight Simulator nicht erkannt werden, wenn MSFS unter Linux über Steam/Proton ausgeführt wird.
Es gibt Berichte, dass ähnliche Linux-/udev-Lösungen bei Flugsimulator-Hardware unter Proton geholfen haben.
Allerdings:
Ich habe diese Lösung selbst NICHT mit MSFS unter Linux/Proton getestet oder verifiziert.
Bei MSFS/Proton können zusätzliche Anforderungen rund um Steam Input, HID/HIDRAW oder Proton selbst bestehen. Daher würde ich die oben beschriebene udev-Prüfung als sinnvollen ersten Schritt bei der Fehlersuche betrachten, nicht als garantierte MSFS-Lösung.
Ich hoffe, das erspart jemand anderem ein paar Stunden Fehlersuche. 🙂
By
LooneySheep ·
![Rafi [Aerosoft]](https://forum.aerosoft.com/uploads/monthly_2026_02/Rafi.thumb.jpeg.4a2295ac3b06910d02314bef45e636ec.jpeg)
