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, public chip labels capture what the tester felt. The separate response-notes field stays private; it can contain optional typed text and, on Linux, probe-measured X/Y motion.

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

Windows groups the live battery into Constant, Periodic, Condition, and Ramp sections. Linux presents the equivalent evdev effects that each device advertises. Exact counts vary by driver and hardware on both platforms.

Current Linux releases also sample the stick's X/Y sensors while each live effect plays, recording measured displacement alongside the tester's answer so a false 'did nothing' response is easier to spot. That measurement stays in the private response-notes field and is not rendered on public device pages.

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

The AppImage can run in place, or ./FfbProbe-*.AppImage --install can add user-scoped desktop integration under ~/Applications. Use --uninstall to remove that installed copy and its menu entry.

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.

Consent-first updates on Windows and Linux

The GUI reads a small stable-release manifest at startup. It sends no install ID, current-version query, device information, or probe results; offline and malformed responses stay silent.

After explicit consent, FFB-Probe downloads the installer, verifies its exact length and SHA-256, requires a valid Windows signature from Rohsam Inc., runs the per-user installer silently, and restarts the new build.

A running Linux AppImage can download and verify the new AppImage, invoke its user-scoped install handler, refresh the desktop entry and icons, and launch the installed copy.

Development builds, extracted AppDirs, distro packages, and other non-AppImage Linux installs are never overwritten. The prompt links to the download page and these release notes instead, and every user can defer or skip a version.

Known issues and recovery steps

The literal bytes are the audit surface

Your report files remain local unless you click Share. Sharing POSTs the JSON file to /submit; those are the same bytes embedded at the bottom of the HTML report. Separately, the GUI performs the identifier-free startup manifest check described above, but it never sends report or device data as part of that check.

The public hardware database renders an aggregate view per VID:PID. It never displays responses[].notes, which can contain optional tester text and Linux probe-measured motion. Chip selections, capability flags, supported effects, result codes, failed effects, and run errors can appear on the device page.

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