How FFB Probe works

The guided run

FFB Probe is organized around one short tester journey: land on the value-prop screen, detect the stick, confirm the safety checklist, feel each live effect, answer what happened, then keep or share the resulting report. Each screen focuses on the task at hand so testers always know what to do next.

Step 01

Land

First-launch landing explains what FFB Probe is, what the test takes, and why the public hardware database matters before the tester does anything.

Step 02

Detect

The next screen identifies the joystick, VID:PID, and force-feedback capability — and shows a live readout of the stick — before any force is played.

Step 03

Prepare

The checklist makes the tester close simulators, clear desk space, keep a hand on the stick, and handle FFB2 grip-sensor quirks.

Step 04

Feel

The running view shows the live section, expected signal, countdown, and the current effect without hiding the Stop control.

Step 05

Answer

After each effect, two surfaces capture the tester's response: a chip grid (multi-select, public — these labels appear on the device's hardware-DB page) and an optional free-text notes box (private — kept server-side, never on the public page).

Step 06

Keep or share

The result page keeps reports local by default. Sharing sends the redacted hardware payload, and an optional email field lets you ask for a heads-up if FFB-Bridge starts supporting your stick.

What the probe asks the hardware to do

The standard Windows battery presents four GUI-visible live sections: Constant, Periodic, Condition, and Ramp. Counts can vary because the probe respects what each driver actually enumerates.

The two files each run writes

Reports save to %LOCALAPPDATA%\Programs\ffb-probe\Results\FFB-Probe-<timestamp>\ on Windows and ~/.local/share/ffb-probe/Results/FFB-Probe-<timestamp>/ on Linux. Two files per run; the HTML embeds the JSON in a <pre> block so the local report and the upload payload are guaranteed to be the same bytes — no second hidden artifact.

Windows install and publisher checks

FFB Probe is published by Rohsam Inc. The installer is a per-user install — no admin password required, no UAC prompt. It places the binary under %LOCALAPPDATA%\Programs\ffb-probe and writes a desktop shortcut and a Start Menu entry. The directory chooser is hidden so you can't accidentally install somewhere weird. Stable Windows releases are signed; confirm Windows shows Rohsam Inc. as the publisher and verify the SHA-256 on the Download page before running.

If Windows does not show Rohsam Inc. as the verified publisher for your installer, or if the hash does not match the published manifest, do not run that file.

The release manifest is the source of truth for filenames, sizes, and hashes. The Windows installer and Linux AppImage are both opt-in downloads; running the probe still keeps reports local until you choose Share.

AppImage plus evdev permissions

The Linux build ships as a self-contained AppImage. Mark it executable, run it, and keep the stick powered with room to move:

chmod +x ./FfbProbe-*.AppImage
./FfbProbe-*.AppImage

Detection can work with read-only access, but live effects need write access to the joystick's /dev/input/event* node. If the wizard reports permission failures, fix the device's event-node permissions once instead of running the whole AppImage with sudo.

1. Find the event node

The report or error text usually names it as something like event=/dev/input/event2. You can also inspect joystick event symlinks:

ls -l /dev/input/by-id/*event-joystick

2. Try a temporary permission

Replace event2 with the node for your stick. This lasts until the device is unplugged or the machine reboots, so it is a safe way to confirm the problem:

sudo setfacl -m "u:$USER:rw" /dev/input/event2
./FfbProbe-*.AppImage

3. Make it persistent with udev

Ask udev for the stick's USB IDs:

udevadm info -q property -n /dev/input/event2 | grep -E 'ID_VENDOR_ID|ID_MODEL_ID|NAME'

Use those lowercase hex IDs in a device-specific rule. This example is for a SideWinder FFB2, VID:PID 045e:001b:

sudo tee /etc/udev/rules.d/70-ffb-probe-045e-001b.rules > /dev/null <<'EOF'
# FFB Probe: allow the active desktop user to open this joystick's event node.
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="001b", TAG+="uaccess"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=input

Unplug and replug the stick, then run the AppImage normally. The rule is per-device, so it is safer than adding your user to the broad input group.

The Linux wizard uses evdev force-feedback effects rather than DirectInput. The shared report schema is the same as Windows, so Linux submissions appear in the same public database and OS breakdown.

Known issues and recovery steps

The literal bytes are the audit surface

Running the probe locally does not send anything — the two files stay on disk. Clicking Share POSTs the JSON file to /submit on this server. That JSON is the same bytes embedded at the bottom of the HTML report; you can read it before sharing.

The public hardware database renders an aggregate view per VID:PID. The only field never displayed is the per-effect free-text notes — what the tester typed in the optional notes box during the run. Everything else (chip selections, capability flags, supported effects, HRESULT codes, failed effects, run errors) appears on the device page exactly as the probe wrote it.

Read the full privacy contract → · Open the sample uploaded report →