Christian Schaller brachte einen nicht unterstützten Filmscanner dazu, unter Linux einen erkennbaren Scan zu erzeugen, nachdem er die USB-Sendungen seines Windows-Treibers aufgezeichnet hatte. In seinem Bericht vom 15. Oktober beschreibt er, wie Claude bei der Analyse dieser Mitschnitte und der Entwicklung eines SANE-Backends half. Der erste Scan hatte noch Qualitätsprobleme; später berichtete er von einem deutlich besseren Treiber. Das sind Ergebnisse eines Entwicklers und eines Scanners, keine unabhängig reproduzierte Messung dazu, wie oft KI Treiber schreiben kann.

Anschließend veröffentlichte Schaller hw-harness, eine MIT-lizenzierte Sammlung von Skripten und Dokumentation, die seine Methode verallgemeinert. Er betont, dass die Scanner- und Kameraprojekte eigens geschriebenen Code nutzten, nicht das veröffentlichte Harness in seiner jetzigen Form. Für Linux-Treiberentwickler mit physischem Zugriff auf ein nicht unterstütztes USB-Gerät ist die sinnvolle Aufgabe enger als „die KI Reverse Engineering machen lassen“: einen Vorgang mit dem funktionierenden Herstellertreiber mitschneiden, denselben Vorgang mit dem Linux-Treiber mitschneiden und den ersten bedeutsamen Unterschied untersuchen.

Die große Veränderung

  • Was sich geändert hat: Schaller hat einen wiederholbaren Weg gebündelt, um eine funktionierende Windows-Gerätesitzung und einen Linux-Treiberversuch mit demselben hostseitigen USB-Rekorder zu beobachten. Sein Scannerergebnis zeigt, warum der Vergleich helfen kann, bleibt aber ein einzelner berichteter Fall.
  • Warum das wichtig ist: Ein Treiberentwickler kann einem KI-Programmierassistenten beschriftete Mitschnitte geben und um eine Protokollerklärung oder ein kleines Prüfprogramm bitten. Vor der Übernahme erzeugten Codes braucht er weiterhin Hardware, einen funktionierenden Referenzvorgang und direkte Tests.
  • Worauf zu achten ist: Die Methode hängt davon ab, ob der relevante Geräteverkehr beobachtbar ist. Bei einer internen MIPI-Kamera nutzt das veröffentlichte Harness stattdessen Windows-Gerätekonfiguration und ACPI-Untersuchungen; eine USB-Aufzeichnungsanleitung würde die benötigten Informationen verfehlen.

Was vor einer Aufzeichnung nötig ist

Die hw-harness-README nennt Fedora als Entwicklungs- und Testumgebung. Die dokumentierte Einrichtung erfordert libvirt/KVM, einen Windows-Gast mit dem Herstellertreiber, echtes USB-Passthrough, usbmon-Aufzeichnung auf dem Linux-Host und einen Linux-Treiber oder ein Prüfprogramm zum Vergleich. Windows 11 Pro ermöglicht die RDP-basierten GUI-Steuerungen des Harness. Der VM-Leitfaden sagt, dass ein Home-Gast weiterhin SSH, aber nicht diese RDP-Steuerungen nutzen kann. Das Repository nennt Fedora-Pakete und Gruppenrechte; führen Sie harness doctor in der ausgecheckten Revision aus, um vor dem Anschließen des Geräts fehlende Teile zu finden.

Halten Sie eine zulässige Windows-Installation und Herstellersoftware, das genaue Gerät, einen wiederholbaren Vorgang und Platz für Paketmitschnitte bereit. Planen Sie VM, Hardwarezugriff, Windows und den gewählten KI-Dienst ein; das Repository nennt keine festen Gesamtkosten. Seine Skripte stehen unter MIT-Lizenz, die jedoch keine Windows- oder Herstellersoftwarelizenz erteilt. Prüfen Sie vor Nutzung oder Weitergabe der gesammelten Daten eigene Lizenzbedingungen und geltende Reverse-Engineering-Regeln.

Verwenden Sie pro Gerät ein eigenes Projektverzeichnis. Laut README erzeugt harness init die Konfiguration und die von der Versionsverwaltung ignorierten Verzeichnisse etc/ und captures/. Tragen Sie VM-Namen und USB-Hersteller-/Produkt-IDs des Geräts ein, statt die README-Beispielwerte zu kopieren. winctl auth, harness iso und das dokumentierte Gast-Bootstrapping richten die Steuerung der Windows-VM ein; winctl status sollte vor einer Aufzeichnung ssh: ok melden. Das ist die dokumentierte Einrichtung des Projekts, keine von BIG CHANGE ausgeführte Schrittfolge.

Denselben Vorgang auf beiden Systemen abgleichen

  1. Ausgangszustand und Windows-Referenz aufzeichnen. Folgen Sie dem Methodendokument des Repositorys: Lernen Sie zunächst das Leerlaufverhalten kennen. Beginnen Sie den Host-Mitschnitt vor der Übergabe des USB-Geräts an den Gast, wenn die anfängliche Geräteerkennung benötigt wird. Führen Sie den Windows-Herstellertreiber mit dem durchgereichten Gerät aus und beschriften Sie eine kurze, bestimmte Aktion, etwa einen Scan mit genannter Auflösung. usbcap zeichnet den Bus auf und schreibt eine .meta-Begleitdatei mit Gerät, Busadresse, Dauer und Beschriftung. Der hostseitige Aufzeichnungspunkt liegt unterhalb des USB-Passthroughs und kann so den Vorgang des Gasts beobachten.
  2. Den entsprechenden Linux-Vorgang aufzeichnen. Geben Sie das Gerät an den Host zurück und zeichnen Sie den Linux-Treiber beim selben Vorgang mit denselben Einstellungen und demselben physischen Material auf. Ein Referenzmitschnitt ohne entsprechenden Linux-Lauf kann nicht zeigen, welche Treiberaktion abwich. Der Scannerbefehl des Repositorys ist ein Beispiel für die Umgebung des Autors, kein universeller Befehl für jedes Gerät.
  3. Vergleichen und eine Hypothese testen. Lesen Sie die beiden Mitschnitte in Wireshark oder mit den tshark-Filtern des Methodendokuments. Prüfen Sie Initialisierungsübertragungen, Schreibvorgänge vor und nach der Aktion, Statusabfragen und das Timing von Bulk-Übertragungen. Ändern Sie jeweils nur eine Einstellung, etwa die Auflösung, um veränderte Übertragungen zu erkennen. Lassen Sie einen KI-Assistenten einen möglichen Unterschied nennen und den zugrunde liegenden Mitschnitt samt Frame angeben. Nehmen Sie dann eine begrenzte Treiberänderung vor oder erstellen Sie ein Prüfprogramm und wiederholen Sie denselben Vorgang an echter Hardware. Eine plausible Modellerklärung ist kein Erfolgssignal.

Das unmittelbare Ergebnis sind zwei beschriftete Aufzeichnungsdateien und eine Beschreibung der ersten bedeutsamen Abweichung. Eine erfolgreiche Reparatur erfordert, dass das Linux-Gerät nach eigenen Prüfungen des Entwicklers den beabsichtigten Vorgang zuverlässig mit dem erwarteten Ergebnis ausführt. Einige übereinstimmende Bytes oder ein Teilbild belegen keine vollständige Treiberqualität. Laut Schallers Bericht erforderte der erste erkennbare Scan weitere Arbeit; währenddessen erschien unabhängig davon Upstream-SANE-Unterstützung für seinen Scanner.

Sind die Mitschnitte schwer vergleichbar, verkürzen Sie den Vorgang und prüfen Sie Gerät, Einstellungen und Aufzeichnungsebene auf Übereinstimmung. Die Methode empfiehlt kleine Mitschnitte für jeweils eine Frage und eine einmalige Aufzeichnung des Anschließens. Schlagen Passthrough oder Gaststeuerung fehl, nutzen Sie harness doctor, hostdev status und den VM-Einrichtungsleitfaden, bevor Sie einen leeren Mitschnitt als Treiberfehler interpretieren. Bewahren Sie Originalmitschnitte und Notizen auf, damit sich eine vorgeschlagene Registerkonstante auf einen beobachteten Frame zurückführen lässt.

Wo USB-Aufzeichnung endet

Eine interne MIPI-Kamera legt dem Host-USB-Rekorder nicht denselben nützlichen Verkehr offen. Das Methodendokument beschreibt stattdessen winctl probe für Windows-PnP-Eigenschaften, INF-Dateien, Registry-Einträge und ACPI-Tabellen sowie Linux-Untersuchungen mit hwdbg. Schaller berichtet, diesen anderen Weg mit Kernel- und libcamera-Patches auf seine Laptopkamera angewendet zu haben; auch diese Ergebnisse stammen aus seinem Bericht. Nehmen Sie ein Kameraergebnis nicht als Beleg dafür, dass die USB-Schleife auf einem anderen Gerät funktionierte.

Beschränken Sie die Untersuchung auf beobachtetes Geräteverhalten und deklarative Konfiguration. Der Clean-Room-Leitfaden des Repositorys schließt das Disassemblieren von Herstellerbinärdateien und das Kopieren ihres Codes in einen Linux-Treiber aus. Er warnt außerdem vor Geräteseriennummern in Mitschnitten und einem privaten SSH-Schlüssel im Projektverzeichnis. Prüfen Sie Aufzeichnungen, Gerätekennungen und Gastdateien vor der Übergabe an KI-Dienste oder öffentlicher Weitergabe; Schlüssel und Rohmitschnitte gehören nicht in die Versionsverwaltung. Die veröffentlichten Anweisungen geben eine Methode zum Ausprobieren vor. BIG CHANGE hat Blog und Repository an der festgelegten Revision geprüft, aber weder die VM ausgeführt noch ein Gerät aufgezeichnet oder einen daraus entstandenen Treiber validiert.

Quellen und weiterführende Lektüre

  • Christian Schallers Bericht vom 15. Oktober erklärt seine Scanner- und Laptoparbeiten, die von ihm Claude zugeschriebene Rolle und warum das gemeinsame Harness nach den individuellen Skripten entstand. Das Scannerergebnis ist sein Bericht und wurde in diesem Artikel nicht unabhängig reproduziert.
  • hw-harness-Repository beschreibt Werkzeuge, Fedora-/Windows-Voraussetzungen, Beispielkonfiguration und Datenschutzhinweis. BIG CHANGE prüfte Commit 093afc5c576c200f29b771d01624a327d0ff1806 vom 14. Oktober 2026; das Repository ist MIT-lizenziert und kann sich nach dieser Revision ändern.
  • Die Methode legt Ausgangszustand, Referenz, Linux-Vergleich und Wiederholung, Umgang mit Mitschnitten, USB-Lektüre und den separaten Weg für Geräte ohne hostsichtbaren Bus fest.
  • Einrichtung der Windows-Referenz-VM behandelt Gastzugriff, USB-Passthrough und Windows-Pro-/Home-Unterschiede bei RDP-Steuerungen. Prüfen Sie die Lizenzbedingungen Ihrer Installation.
  • Clean-Room-Grenzen erläutern die beobachtungsbasierte Praxis, Grenzen bei Herstellerbinärdateien und die Dokumentation der Herkunft von Konstanten. Es sind technische Projektleitlinien, keine rechtliche Stellungnahme.