Die exakten Bytes, die gesendet werden.

Der SubmissionPayload-Vertrag

Alle Felder dieser Liste sind zwischen identischen Geräten geteilte Gerätespezifikationen, grobe Umgebungsdaten, die Teststärke, Testdiagnosen, ausgewählte kanonische Bezeichnungen oder Antwortnotizen. Antwortnotizen können unter Windows und Linux die von der Sonde gemessene X/Y-Bewegung sowie optional von Ihnen eingegebenen Text enthalten.

• device – VID:PID, Gerätename, Geräteklasse (device_type: flight, joystick, gamepad, wheel, other oder unknown), Achsen, Tasten, POVs, Abtastzeitraum, Zeitauflösung, Firmware-Revision, Hardware-Revision, FF-Treiberversion, Fähigkeitsflags und die Liste der unterstützten Effekte mit Typflags.
• os — Familie (Windows / Linux), Hauptversion, Build, Architektur und .NET-Laufzeitversion. Jeder Wert ist eine grobe Umgebungsangabe, die viele Installationen gemeinsam haben.
• run — die Teststärke, mit der jeder Effekt wiedergegeben wurde (strength_pct), und ob es der Standardwert des Geräts oder Ihre eigene Wahl war (strength_source). Geräteseiten zeigen, wie viele Berichte mit welcher Stärke gelaufen sind.
• responses — je Effekt: ausgewählte kanonische Bezeichnungen (veröffentlicht) und ein Antwortnotizfeld, das optional eingegebenen Text sowie die von der Sonde gemessene Bewegung enthalten kann, also vorzeichenbehaftete X/Y-Spitzenwerte als Prozentsatz des halben Bereichs jeder Achse (gespeichert, aber nie auf der öffentlichen Hardwareseite dargestellt).
• diagnostics – OK / FAIL: DIERR_…-Ergebnisse pro Effekt (geschlossenes Vokabular, Zeigeradressen entfernt), das Rollup der fehlgeschlagenen Effekte und alle Orchestratorfehler mit Dateipfaden, die per regulärem Ausdruck zu <path> geschwärzt wurden. Wird auf der öffentlichen Hardwareseite veröffentlicht, damit Treiberautoren und Toolentwickler darauf reagieren können.
• probe_version und submitted_date – nur Datum (keine Uhrzeit).

Lesen Sie das wörtliche Nutzlastformat auf der Beispielberichtsseite →

Nicht im Berichtspayload und nicht von /submit akzeptiert

Das geteilte Berichts-JSON hat ein einziges Schema, und die App sendet nichts außerhalb davon. Enthält eine Anfrage ein Feld, das nicht im Schema steht, veröffentlicht /submit es nie. Diese Angaben sind niemals Teil eines Berichts, den die App einsendet:

• DirectInput Instanz-GUID – Hash pro Maschine, eine direkte Maschinenkennung.
• Produkt-GUID – doppelte Hardwareidentität über VID:PID hinaus.
• Roher DirectInput-Gerätename erkannter Hardware – manchmal vom Benutzer festgelegt. Für eine VID:PID aus der Gerätetabelle der App wird stattdessen deren Anzeigename gesendet. Für ein Gerät, das die Tabelle nicht kennt, sendet die App den Modellnamen, den Sie auf Nachfrage eingegeben haben, oder andernfalls einen bereinigten, vom Treiber gemeldeten Namen; dieser Name wird als Gerätename veröffentlicht.
• USB-Geräteliste – jedes USB- und HID-Gerät auf dem Host. Starke Oberfläche mit Fingerabdrücken.
• Liste der installierten Software – kein Registry Walk, keine Simulatorinventur, keine SDK-/Laufzeitinventur.
• Vollständige Beschreibung des Betriebssystems – genaue Host-Strings sind zu fingerabdruckbar. Die Nutzlast verwendet grobe Betriebssystemfamilien-/Versionsfelder.
• Dateipfade in Fehlermeldungen – Pfade wie C:\Users\… oder /home/… werden vor der Serialisierung geschwärzt.
• Debug-Protokolle – vom öffentlichen Einreichungsendpunkt nicht akzeptiert.
• Laufzeit der Wanduhr – beim übermittelten Datum handelt es sich nur um das Datum, nicht um die genaue Uhrzeit.
• Namen anderer laufender Programme — die Warnung auf dem Willkommensbildschirm und die Meldung zum exklusiven Zugriff nennen Programme, die Ihr Gerät belegen können, aber nur auf Ihrem Bildschirm. Diese Namen werden nicht in den Bericht übernommen.
• E-Mail- und Kontaktfelder — niemals Teil des Berichtspayloads. Nach dem Teilen eines Berichts bietet die GUI eine separate optionale Benachrichtigungsanmeldung an, die nur E-Mail + VID:PID an /notify sendet und getrennt von Einsendungen speichert.

Das eine private Feld

Für die öffentliche Datenbank gilt: Wir veröffentlichen alles, was sicher möglich ist. Das vollständige Feld responses[].notes jedes Effekts halten wir bewusst zurück. Es kann von Testpersonen eingegebenen Text enthalten, der versehentlich persönliche Daten umfasst, sowie die daneben gespeicherte, von der Sonde gemessene Bewegung; das gesamte Feld bleibt serverseitig.

Alles andere – Geräteklasse, Fähigkeitsflags, unterstützte Effekte, Betriebssystemfamilie + -version, Teststärke, Auswahlbezeichnungen, HRESULT-Codes (S_OK / DIERR_…-Namen aus geschlossenem Vokabular), Übersicht fehlgeschlagener Effekte, Ausführungsfehler mit geschwärzten Pfaden, die Sondennotiz – wird auf der Geräteseite genau so dargestellt, wie die Sonde es gemeldet hat. Treiberautoren, Sim-Entwickler und Tool-Entwickler brauchen diese Daten, um handeln zu können; sie öffentlich zu machen ist der ganze Sinn des Projekts.

Eine Einreichung entfernen

Wenn Sie einen Bericht geteilt haben und ihn entfernen lassen möchten, schreiben Sie an [email protected] mit dem Supportcode, den die App nach dem Teilen angezeigt hat (er beginnt mit PRB-). Ohne den Code senden Sie stattdessen die VID:PID des Geräts und das ungefähre Einsendedatum. In beiden Fällen ist kein Konto nötig.

Wenn Sie sich für die E-Mail-Benachrichtigung nach der Übermittlung entschieden haben, wird diese Adresse separat gespeichert und kann unabhängig entfernt werden. Senden Sie eine E-Mail an denselben Posteingang mit „E-Mail entfernen“ und der Adresse.

Herausgegeben von Rohsam Inc.

FFB Probe wird von Rohsam Inc. herausgegeben, einem kanadischen Softwareherausgeber mit Sitz in Toronto, Ontario.

Rohsam Inc.
2727 Steeles Ave West, Unit 103-886
Toronto, ON M3J 3G9
Canada

Für Anfragen zu Datenschutz, Löschung oder Produktsupport wenden Sie sich an [email protected]. Für Anfragen zu Geschäftlichem oder zur Herausgeber-Validierung wenden Sie sich an [email protected].