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 つのファイルはそれぞれ実行すると書き込みます

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

未署名のインストーラーの警告を超えて

インストーラーはユーザーごとにインストールされます。管理者パスワードや UAC プロンプトは必要ありません。バイナリを以下に配置します %LOCALAPPDATA%\Programs\ffb-probe そして、デスクトップ ショートカットと Start Menu エントリを書き込みます。ディレクトリ選択機能は非表示になっているため、誤って奇妙な場所にインストールすることはありません。 SHA-256 を確認する ダウンロード ページにあるファイルは、実行前に持っていたファイルと一致します。

ベータ ビルドはまだコード署名されていません。コード署名は v1.0 ロードマップに含まれています。警告が 2 つ表示されます。どちらも予期されています。

v1.0 リリースがコード署名証明書とともに出荷されると、両方の警告が表示されなくなり、SAC がインストーラーをブロックしなくなります。それまでは、警告を問題の証拠としてではなく、予想どおりに扱ってください。

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 ファイルを次の宛先に POST します。 /submit このサーバー上で。その JSON は、HTML レポートの下部に埋め込まれているバイトと同じです。共有する前に読むことができます。

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

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