FFB Probe の仕組み

ガイド付き走行

FFB Probe は、1 回の短いテスターの旅を中心に構成されています。つまり、バリュープロップ画面に着地し、スティックを検出し、安全チェックリストを確認し、それぞれのライブ効果を感じ、何が起こったのかに答え、結果のレポートを保存または共有します。各画面は目の前のタスクに焦点を当てているため、テスターは次に何をすべきかを常に把握できます。

ステップ 01

土地

最初の起動の着陸では、テスターが何かを行う前に、FFB Probe とは何か、テストに必要な内容、およびパブリック ハードウェア データベースが重要である理由が説明されます。

ステップ 02

検出する

次の画面では、ジョイスティック、VID:PID、およびフォースフィードバック機能が識別され、フォースが再生される前のスティックのライブ読み出しが表示されます。

ステップ 03

準備する

チェックリストにより、テスターはシミュレータを近くに置き、机のスペースを空け、スティックに手を添えたままにし、FFB2 グリップ センサーの癖に対処するようになります。

ステップ 04

感じる

実行中のビューには、Stop コントロールを隠すことなく、ライブ セクション、予期される信号、カウントダウン、および現在のエフェクトが表示されます。

ステップ 05

答え

各エフェクトの後、2 つのサーフェスがテスターの応答をキャプチャします。チップ グリッド (複数選択、パブリック - これらのラベルはデバイスのハードウェア DB ページに表示されます) とオプションの自由テキスト ノート ボックス (プライベート - サーバー側に保持され、パブリック ページには表示されません)。

ステップ 06

保存または共有

結果ページでは、デフォルトでレポートがローカルに保持されます。共有すると、編集されたハードウェア ペイロードが送信され、オプションの電子メール フィールドを使用して、FFB-Bridge がスティックのサポートを開始する場合に注意を求めることができます。

プローブがハードウェアに要求すること

標準の Windows バッテリーには、GUI に表示される 4 つのライブ セクション (Constant、Periodic、Condition、および Ramp) が表示されます。プローブは各ドライバーが実際に列挙したものを尊重するため、カウントは異なる場合があります。

2 つのファイルはそれぞれ実行すると書き込みます

レポートは、Windows では %LOCALAPPDATA%\Programs\ffb-probe\Results\FFB-Probe-<timestamp>\ に、Linux では ~/.local/share/ffb-probe/Results/FFB-Probe-<timestamp>/ に保存されます。実行ごとに 2 つのファイルが作成され、HTML は <pre> ブロック内に JSON を埋め込むため、ローカル レポートとアップロード ペイロードは同じバイトであることが保証されます。2 番目の隠れたアーティファクトはありません。

Windows へのインストールと発行元の確認

FFB Probe は Rohsam Inc. によって発行されています。インストーラーはユーザーごとにインストールされ、管理者パスワードや UAC プロンプトは必要ありません。バイナリは %LOCALAPPDATA%\Programs\ffb-probe の下に配置され、デスクトップ ショートカットと Start Menu エントリが書き込まれます。ディレクトリ選択機能は非表示になっているため、誤って奇妙な場所にインストールすることはありません。安定版の Windows リリースには署名が付いています。実行する前に、ダウンロード ページで Windows が発行元として Rohsam Inc. を表示していることと、SHA-256 を確認する を確かめてください。

Windows がインストーラーの検証済み発行元として Rohsam Inc. を表示しない場合、またはハッシュが公開マニフェストと一致しない場合は、そのファイルを実行しないでください。

リリース マニフェストが、ファイル名、サイズ、ハッシュに関する信頼できる情報源です。Windows インストーラーと Linux AppImage はどちらもオプトインのダウンロードです。プローブを実行しても、Share を選択するまでレポートはローカルに保持されます。

AppImage および evdev 権限

Linux ビルドは、自己完結型の AppImage として出荷されます。これを実行可能としてマークして実行し、スティックに十分な電力が供給された状態で移動できるようにします。

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

検出は読み取り専用アクセスで機能しますが、ライブエフェクトにはジョイスティックの /dev/input/event* ノードへの書き込みアクセスが必要です。ウィザードが権限の失敗を報告した場合は、AppImage 全体を sudo で実行するのではなく、デバイスのイベント ノードの権限を一度だけ修正してください。

1. イベントノードを見つける

レポートまたはエラー テキストでは通常、event=/dev/input/event2 のような名前が付けられています。ジョイスティック イベントのシンボリックリンクを検査することもできます。

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

2. 一時的な許可を試してください

event2 を、お使いのスティックのノードに置き換えてください。これはデバイスのプラグが抜かれるかマシンが再起動するまで続くため、問題を確認する安全な方法です。

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

3. udev を使用して永続化します。

スティックの USB ID については、udev に問い合わせてください。

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

これらの小文字の 16 進 ID をデバイス固有のルールで使用します。この例は、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

スティックを取り外して再度接続し、AppImage を通常どおり実行します。ルールはデバイスごとであるため、ユーザーを広範な input グループに追加するよりも安全です。

Linux ウィザードは、DirectInput ではなく evdev フォースフィードバック エフェクトを使用します。共有レポートのスキーマは Windows と同じであるため、Linux の送信は同じパブリック データベースと OS 内訳に表示されます。

既知の問題と回復手順

リテラルバイトは監査面です

プローブをローカルで実行しても何も送信されません。2 つのファイルはディスク上に残ります。Share をクリックすると、JSON ファイルがこのサーバー上の /submit に POST されます。その JSON は、HTML レポートの下部に埋め込まれているバイトと同じです。共有する前に読むことができます。

パブリック ハードウェア データベースは、VID:PID ごとに集計ビューをレンダリングします。表示されない唯一のフィールドは、エフェクトごとの 自由記述メモ、つまりテスターが実行中にオプションのメモ ボックスに入力した内容です。その他すべて (チップ選択、機能フラグ、サポートされているエフェクト、HRESULT コード、失敗したエフェクト、実行エラー) は、プローブが書き込んだとおりにデバイス ページに表示されます。

プライバシー契約全文を読む→ · アップロードされたサンプルレポートを開く →