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

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 shows a non-blocking Review and fix banner naming each problem.

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.

Figure 2. Support → Health shows a supported event-node PASS, a stale udev-rule WARN with Fix, and a physical-device FAIL.

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

Health checks verify that /etc/udev/rules.d/99-ffb-bridge.rules covers every current supported-device input line and the MOZA TTY permissions. Fix previews the canonical curated rule, installs it through pkexec, reloads udev, and triggers input and TTY devices. A connected opted-in unlisted joystick is appended during installation.

An older event-only rule is reported as WARN because it lacks the current MOZA TTY permissions. Use Fix even if the file already exists; the app replaces it with the complete generated rule.

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; Restart later is safe when you need to continue first.

Figure 4. The Linux fix dialog previews the canonical supported-device input and MOZA TTY rule before requesting permission. A connected opted-in unlisted joystick is appended during installation.

Figure 5. 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; Restart later is safe when you need to continue first.

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.