Support page
The Support page is the single home for documentation, health checks, diagnostics, logs, and support-bundle export. Physical device configuration now lives under Hardware.
Tab strip
The Support page opens on the Resources tab, with links to the online docs and bundled PDF. The other two tabs are one click away:
- Resources (opens first) — official documentation and the PDF manual. Replay the welcome orientation from Settings → General.
- Health checks — the everyday triage surface (device, udev rule on Linux, sim reachability, runtime state). Click Run checks to probe.
- Diagnostics — runtime metrics, the searchable event log, and one-click support-bundle export. Documented separately on the Diagnostics tab page.
Device selection, direction calibration, validated rendering, strength limits, and control assignments live under Hardware.
Health checks tab
Health checks is the path most testers need when something looks off. Click Run checks to probe the bridge state. Rows update independently, so a slow sim probe does not block the device or runtime result from appearing.
- PASS means the bridge verified that part of the setup.
- INFO means nothing is wrong, but the row has useful context. For example, X-Plane not listening is expected when you are flying MSFS or using Mock mode.
- WARN means the setup can continue, but there is something worth fixing or reporting.
- FAIL means the bridge found a blocking problem. When Health checks knows a safe fix, the row offers an action button.
- READY and CHECKING are neutral states used before and during a run.
Automatic device preflight
At launch, FFB-Bridge quietly checks the device backend on Windows, Linux, and macOS. Linux also checks read/write access to a supported event node and whether the installed udev rule covers every current device permission. WARN or FAIL opens a dialog naming each problem, with Review and fix now and Dismiss for now.
- If all checks pass, nothing opens.
- Startup does not probe the simulator or network; a closed sim is normal and remains a runtime concern.
- While the dialog is open, Auto-arm waits. Review and fix the issue, or dismiss it when the device is intentionally disconnected; after dismissal, Auto-arm can continue only if its other prerequisites pass.
Hardware
The former Support-page hardware controls now have a dedicated area. Use Flight Check for isolated effect tests and use Hardware for persistent physical-device settings. Open the hardware guide.
How checks are laid out
Every check row has four parts:
- Status — PASS (green), INFO (blue), WARN (amber), FAIL (red), READY / CHECKING (neutral), or N/A when the row does not apply on this platform.
- Title — what's being checked.
- Detail — a one-line summary of what was found. Hover (or tap on touch) to see the full detail.
- Action button — present only when there's something actionable. Examples: Install local entry, Use port 5111, Fix….
The checks
FFB joystick device
Confirms a supported force-feedback joystick is visible to the OS and the bridge can open it exclusively. Fails if no supported VID/PID is present, or if another process is holding the handle.
Linux udev rule
Health checks verify that /etc/udev/rules.d/71-ffb-bridge.rules covers every current supported-device input line, the MOZA TTY permissions and the hidraw access used by the Logitech G940 and Brunner bases. Fix… previews the canonical curated rule, installs it through pkexec, removes the former 99-ffb-bridge.rules, reloads udev, and triggers input, TTY and hidraw devices. A connected opted-in unlisted joystick is appended during installation.
An older rule is reported as WARN when it lacks a current device permission, such as the MOZA TTY lines or the hidraw access used by the Logitech G940 and Brunner bases, or when its file name makes it run too late for desktop-session access, as with the former 99-ffb-bridge.rules. Use Fix… even if the file already exists; the app installs the complete generated rule as 71-ffb-bridge.rules and removes the former file.
After a successful repair, the rule is active and the app recommends a restart. Restart now reopens the joystick with the new permissions and drops any startup fallback; choosing I’ll restart later is safe when you need to continue first.
Health checks detects NixOS (by looking for /etc/NIXOS) and replaces the udev-rule row with an instruction to add the rule to configuration.nix instead. See
Install for the snippet.
WindowsLinux MSFS SimConnect config
SimConnect is the MSFS path, so this check runs on Windows and Linux. It looks for MSFS's SimConnect.xml in the platform-appropriate location, parses it, and compares any enabled IPv4 entries against the port the bridge is using. Three possible outcomes:
- Matching entry found. Green — nothing to do.
- Entry at a different port. Amber — offers a Use port :X button to adopt that port.
- No usable entry (or unparseable file). Red — offers a Fix… button that opens the install dialog (see below).
MSFS ships its stock SimConnect entry on port 500. On Windows that binds fine and the bridge uses it. Under Proton on Linux, a user-namespace process can't bind ports below 1024, so the bridge installs and uses a parallel entry on an unprivileged port (5111 by default) that MSFS-in-Proton can actually bind — which is why the Linux fix and the Use port action point at that higher port.
MSFS reachability
Probes the configured TCP port. Sends a real SimConnect OPEN packet and inspects the response header so it can distinguish MSFS is listening from something else is listening.
X-Plane reachability
The X-Plane connection is available on Windows, Linux and Apple Silicon macOS. This check sends an RREF probe to
127.0.0.1:49000 and waits briefly for a dataref in response. Maps both timeout and Winsock's
WSAECONNRESET (received when an ICMP port-unreachable was delivered) to “not running”.
Runtime state
Summarizes the current device, data-source, telemetry and exception state. PASS means the device is open and live sim or Mock Sim data is driving the pipeline; INFO means the device is open without live sim data, which is expected while the sim is closed; FAIL means the device is not open.
Crash report
If the previous session crashed, FFB-Bridge shows a crash-report dialog at the next start rather than a Health checks row. Use Copy to copy the saved stack trace, and Open feedback form to open the feedback page in your browser, where you can paste the log and attach a support bundle.
Fix dialog
Fix… buttons don't apply changes directly — they open a dialog that shows exactly what's about to change, where, and (on Linux) what the auth prompt will ask you to approve.
The dialog is always additive: existing entries are never overwritten. If the target file is unparseable, the dialog explains that a timestamped backup will be taken first. Cancel is always the safe choice.
Linux pkexec behaviour
Actions that write to system paths (udev rules, anything under
/etc) route through pkexec. You'll see your distro's normal polkit prompt — the same one that pops up for gparted or a package manager GUI. Exit codes Health checks interprets:
| Exit | Meaning | Health checks reports |
|---|---|---|
0 | Success | Green check; row re-evaluates. |
126 | User dismissed the auth prompt | Amber “Cancelled” — try again when ready. |
127 | No polkit agent / auth failure | Red “Authentication failed.” |
Running the bridge in a minimal environment (headless Linux, sway without a polkit agent) is fine — you just can't use the Support page's privileged fixes. Install the required files manually or start a polkit agent before launching the bridge.
When every check is green
The app should work. If it doesn't, switch to the Diagnostics tab — its event log will show more detail than Health checks' one-line statuses. Or jump to Troubleshooting for common symptoms and fixes.
When MSFS 2020 and 2024 or several installations are present, confirm each named configuration target before repairing it. A repair updates the selected simulator configuration; restart that simulator afterwards. Settings → Session controls which simulator Bridge selects at its next start.