Support page

The Support page (labelled Support in the sidebar) is the single home for everything you'd open when something is wrong, when you need a reference, or when you want to export a support bundle for the developer. Three tabs: Resources, Health checks, and Diagnostics. The hardware compatibility controls that used to live here moved to Settings → Hardware.

Tab strip

The Support page opens on the Resources tab — docs + manual links + the welcome-tour replay sit there as a friendly first landing. The other two tabs are one click away:

Resources (opens first) — links into the docs and manual hosted here, plus the welcome-tour replay and publisher / legal pages.
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.

Hardware compatibility (axis test with invert + pitch/roll swap, effect rendering, the Windows device backend, the device picker, and the Test hardware effects probe) is no longer a Support tab — it lives on Settings → 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.

Hardware controls moved to Settings

The hardware compatibility controls used to be a Support tab. They now live on Settings → Hardware: the live axis test (with Invert axis polarity and Swap pitch/roll axes), the Effect rendering radio (Hardware effects vs Software compatibility mode), the Windows device backend, the device picker for multiple attached sticks, the experimental unlisted-device opt-in, and the Test hardware effects probe. See the Settings page for the full walkthrough.

Figure 2. Settings → Hardware — the axis test (invert + pitch/roll swap), effect rendering, the Windows device backend, and the Test hardware effects probe.

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 udev rule, Use port :5111, Fix….

The checks

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

Checks whether /etc/udev/rules.d/99-ffb-bridge.rules is present and matches the canonical content. When absent, the action is Install udev rule — this triggers a pkexec prompt to write the file into a privileged location.

NixOS exception

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

Linux uses an unprivileged port

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.

SimConnect 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 path works on every platform — and on macOS (Apple Silicon), X-Plane 12 with a SideWinder FFB2 is the supported combination. This check sends a tiny 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

Checks that the control loop is ticking at its target 50 Hz. Warns if the last 60 s mean drops below 45 Hz.

Crash log

If there's a crash log from the last session, the row goes amber and offers Reveal to jump to it in your file manager, and Send via feedback form which pre-populates a feedback submission with the log attached.

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

Tip

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.