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. 🙂

X-Plane Developer

Linux Joystick Permissions - X-Plane Developer

Edit: see the end of the article for a GUI tool to manage joystick permissions. I’ve already briefly discussed some of the changes necessary to get joystick devices working properly but I thought it’d

Das ist nicht neu. Es gibt sogar eine offizielle Anleitungen.

Ich hatte mit den Turtle Beach damals auch die Probleme.

Das kann ich so nicht ganz nachvollziehen:

Fakt ist, dass in Linux-Systemen für alle installierten USB-Devices eine udev-Regel benötigt wird, damit alle, bzw. gewünschten, in dem System definierten User auf das USB-Gerät vollumfänglich zugreifen können. Für die meisten USB-Geräte werden dazu die udev-Regeln im Standard mitgeliefert. Meine Honeycomb-Produkte werden in meiner Linux-Mint Distribution allerdings nicht versorgt und können so nur über einen root-User vollständig angesprochen werden. Das lässt sich aber durch Ergänzung einer udev-Regel einfach ändern, in der die zum Ansprechen des USB-Device notwendigen Zugriffsrechte definiert werden.

Meine beiden in /usr/lib/udev/rules.d gespeichertem "Honeycomb"-udev-Regeln, werden bei jedem Start des Systems ausgeführt und sorgen dafür, dass "ich" als Standard-User vollständig auf die USB-Hardware zugreifen kann. Die Erstellung einer Regel ist denkbar einfach: Es müssen lediglich die per "lsusb" (in einem Terminal ausgeführt) angezeigten Werte "idProduct" und "idVendor" ermittelt und in eine neue udev-Regel übernommen werden. Die gewünschten Zugriffsrechte werden unter "MODE", bei mir auch "0666", eingetragen. Jeweils ein schlichter Zweizeiler, das war's. Anliegend meine beiden udev-Regeln.

52-HoneycombAlpha.rules 52-HoneycombBravo.rules