Edisi Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Gunakan pasangan rekaman USB untuk menyelidiki perangkat yang belum didukung Linux

> Panduan berbasis dokumentasi untuk merekam operasi perangkat keras yang sama dengan driver vendor di Windows dan driver Linux, lalu menguji perbedaannya pada perangkat keras nyata.

By BIG CHANGE Editorial

Published: 2026-10-17T02:51:13.544Z
Updated: 2026-10-17T02:51:13.544Z
Canonical: https://bigchange.ai/blog/compare-usb-traces-linux-device-driver

![Two sheets with abstract trace rows, one orange highlighted, beside a closed generic USB device connected to a small computer.](https://bigchange.ai/api/media/file/usb-trace-comparison-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual captures, identifiable vendor device or tested repair is depicted.

Christian Schaller berhasil membuat pemindai film yang belum didukung menghasilkan pemindaian yang dapat dikenali di Linux setelah merekam apa yang dikirim driver Windows melalui USB. Dalam [catatannya pada 15 Oktober](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/), ia menjelaskan penggunaan Claude untuk membantu menganalisis tangkapan itu dan mengembangkan backend SANE. Pemindaian pertamanya masih bermasalah pada kualitas; kemudian ia melaporkan driver yang jauh lebih baik. Ini hasil satu pengembang dan satu pemindai, bukan pengukuran yang direplikasi secara independen tentang seberapa sering AI dapat menulis driver.

Schaller kemudian menerbitkan [hw-harness](https://github.com/cschalle/hw-harness), kumpulan skrip dan dokumentasi berlisensi MIT yang menggeneralisasi metodenya. Ia menegaskan bahwa proyek pemindai dan kamera memakai kode khusus, bukan harness terbitan dalam bentuknya saat ini. Bagi pengembang driver Linux yang memiliki akses fisik ke perangkat USB tanpa dukungan, tugas yang berguna lebih sempit daripada ‘biarkan AI merekayasa balik’: tangkap satu operasi dengan driver vendor yang berfungsi, tangkap operasi sama dengan driver Linux, lalu selidiki perbedaan pertama yang bermakna.

## Perubahan besar

- **Apa yang berubah:** Schaller mengemas cara yang dapat diulang untuk mengamati sesi perangkat Windows yang berfungsi dan percobaan driver Linux dengan perekam USB sisi host yang sama. Hasil pemindainya menunjukkan mengapa perbandingan itu dapat membantu, tetapi tetap satu kasus yang dilaporkan.
- **Mengapa penting:** Pengembang driver dapat memberikan rekaman berlabel kepada asisten pemrograman AI dan memintanya mengusulkan penjelasan protokol atau program uji kecil. Pengembang tetap memerlukan perangkat keras, operasi acuan yang berfungsi, serta pengujian langsung sebelum menerima kode yang dihasilkan.
- **Yang perlu diperhatikan:** Metode ini bergantung pada apakah lalu lintas perangkat yang relevan dapat diamati. Untuk kamera MIPI internal, harness terbitan beralih ke konfigurasi perangkat Windows dan pemeriksaan ACPI; prosedur rekaman USB akan melewatkan informasi yang dibutuhkan pengembang.

## Yang diperlukan sebelum penangkapan

Dokumen [README hw-harness](https://github.com/cschalle/hw-harness) menyatakan proyek dikembangkan dan diuji di Fedora. Penyiapan terdokumentasi memerlukan libvirt/KVM, guest Windows yang menjalankan driver vendor, passthrough USB nyata, penangkapan `usbmon` pada host Linux, serta driver atau program uji Linux untuk dibandingkan. Windows 11 Pro memungkinkan kontrol GUI harness berbasis RDP. [Panduan VM](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) menyatakan guest Home tetap dapat memakai SSH, tetapi tidak kontrol RDP tersebut. Repositori mencantumkan paket Fedora dan izin grup; jalankan `harness doctor` pada revisi yang telah di-checkout untuk menemukan komponen yang kurang sebelum menghubungkan perangkat.

Siapkan instalasi Windows dan perangkat lunak vendor yang diizinkan, perangkat yang tepat, operasi yang dapat diulang, serta ruang untuk tangkapan paket. Anggarkan VM, akses perangkat keras, Windows, dan layanan AI pilihan Anda; repositori tidak memberikan biaya tetap menyeluruh. Skripnya berlisensi MIT, tetapi itu tidak memberi lisensi Windows atau perangkat lunak vendor. Tinjau ketentuan lisensi Anda serta aturan rekayasa balik yang berlaku sebelum memakai atau mendistribusikan hasil pengumpulan.

Gunakan direktori proyek terpisah untuk setiap perangkat. README menyebut `harness init` membuat konfigurasi serta direktori yang diabaikan oleh kontrol versi, yaitu `etc/` dan `captures/`. Isi nama VM dan ID vendor/produk USB dari perangkat, bukan menyalin nilai contoh README. `winctl auth`, `harness iso` dan penyiapan awal guest yang didokumentasikan membangun kendali atas VM Windows; `winctl status` harus melaporkan `ssh: ok` sebelum penangkapan. Anggap ini sebagai penyiapan terdokumentasi proyek, bukan urutan yang sudah dijalankan BIG CHANGE.

## Samakan satu operasi pada kedua sistem

1. **Rekam kondisi dasar dan acuan Windows.** Ikuti [dokumen metode](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) repositori: pertama pahami bentuk lalu lintas saat tidak aktif. Mulai penangkapan host sebelum menyerahkan perangkat USB ke guest jika Anda memerlukan enumerasi awalnya. Jalankan driver Windows vendor pada perangkat yang diteruskan langsung dan beri label tindakan singkat yang spesifik, misalnya pemindaian pada resolusi tertentu. `usbcap` menangkap bus dan menulis berkas pendamping `.meta` berisi perangkat, alamat bus, durasi, serta label. Titik tangkap host berada di bawah passthrough USB, sehingga dapat mengamati operasi guest.
2. **Rekam operasi padanannya di Linux.** Kembalikan perangkat ke host dan tangkap driver Linux yang melakukan operasi sama dengan pengaturan dan bahan fisik yang sama. Tangkapan acuan tanpa percobaan Linux yang sesuai tidak dapat menentukan tindakan driver mana yang menyimpang. Perintah pemindai di repositori adalah contoh penyiapan penulisnya, bukan perintah universal untuk semua perangkat.
3. **Bandingkan dan uji satu hipotesis.** Baca kedua rekaman di Wireshark atau memakai filter `tshark` dari dokumen metode. Periksa transfer inisialisasi, penulisan sebelum dan sesudah tindakan, polling status, serta waktu transfer bulk. Ubah satu pengaturan setiap kali, misalnya resolusi, untuk melihat transfer yang berubah. Minta asisten AI menunjukkan calon perbedaan serta menyebut tangkapan dan frame yang mendukungnya. Lalu buat perubahan driver terbatas atau program uji dan ulangi operasi sama pada perangkat keras nyata. Penjelasan model yang masuk akal bukan tanda keberhasilan.

Hasil langsungnya adalah pasangan berkas tangkapan berlabel dan penjelasan perbedaan pertama yang bermakna. Perbaikan yang berhasil mensyaratkan perangkat Linux menjalankan operasi yang dimaksud secara konsisten, dengan keluaran yang diharapkan, menurut pemeriksaan pengembang sendiri. Kecocokan beberapa byte atau satu gambar parsial tidak membuktikan mutu driver secara keseluruhan. Dalam catatan Schaller, pemindaian pertama yang dapat dikenali masih memerlukan perbaikan; dukungan pemindainya di proyek hulu SANE muncul secara terpisah saat ia mengerjakannya.

Jika rekaman sulit dibandingkan, persingkat operasi dan pastikan perangkat, pengaturan, serta lapisan penangkapan sama. Metode ini menganjurkan tangkapan kecil yang menjawab satu pertanyaan dan satu kali penangkapan proses penyambungan perangkat. Jika passthrough atau kendali guest gagal, gunakan `harness doctor`, `hostdev status` dan [panduan penyiapan VM](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) sebelum menafsirkan rekaman kosong sebagai kerusakan driver. Simpan tangkapan asli dan catatan agar konstanta register yang diusulkan dapat ditelusuri ke frame yang diamati.

## Batas rekaman USB

Kamera MIPI internal tidak memperlihatkan lalu lintas berguna yang sama kepada perekam USB host. Dokumen metode justru menjelaskan `winctl probe` untuk properti PnP Windows, berkas INF, entri registry, dan tabel ACPI, ditambah pemeriksaan sisi Linux melalui `hwdbg`. Schaller melaporkan penerapan jalur berbeda itu pada kamera laptopnya, dengan patch kernel dan libcamera; hasil tersebut juga berasal dari catatannya. Jangan memakai hasil kamera sebagai bukti bahwa siklus USB bekerja pada perangkat lain.

Batasi penyelidikan pada perilaku perangkat yang diamati dan konfigurasi deklaratif. [Panduan clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) repositori mengecualikan disassembly biner vendor atau penyalinan kodenya ke driver Linux. Panduan juga memperingatkan bahwa tangkapan dapat memuat nomor seri perangkat dan direktori proyek berisi kunci SSH privat. Tinjau rekaman, pengenal perangkat, dan berkas guest sebelum memberikan kepada layanan AI atau membagikannya secara publik; jangan masukkan kunci dan tangkapan mentah ke kontrol versi. Petunjuk terbitan menetapkan metode untuk dicoba. BIG CHANGE meninjau blog dan repositori pada revisi yang dipatok, tetapi tidak menjalankan VM, menangkap perangkat, atau memvalidasi driver yang dihasilkan.

### Sumber dan bacaan lanjutan

- [Catatan Christian Schaller pada 15 Oktober](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) menjelaskan pekerjaan pemindai dan laptopnya, peran yang ia kaitkan dengan Claude, serta mengapa harness bersama muncul setelah skrip khususnya. Hasil pemindai adalah laporannya, tanpa replikasi independen dalam artikel ini.
- [Repositori hw-harness](https://github.com/cschalle/hw-harness) menjelaskan alat, prasyarat Fedora dan Windows, contoh penyiapan, serta peringatan privasi proyek. BIG CHANGE memeriksa commit `093afc5c576c200f29b771d01624a327d0ff1806` bertanggal 14 Oktober 2026; repositori berlisensi MIT dan dapat berubah setelah revisi itu.
- [Metode](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) menetapkan kondisi dasar, acuan, perbandingan Linux dan siklus pengulangan, penanganan tangkapan, pembacaan rekaman USB, serta jalur terpisah untuk perangkat tanpa bus yang terlihat dari host.
- [Penyiapan VM acuan Windows](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) mencakup akses guest, passthrough USB, serta perbedaan Windows Pro dan Home untuk kontrol RDP. Periksa ketentuan lisensi instalasi Anda sendiri.
- [Batas clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) menjabarkan praktik berbasis pengamatan, batas terhadap biner vendor, serta perlunya mencatat asal konstanta. Ini pedoman rekayasa proyek, bukan pendapat hukum.

## Sources

- [Christian Schaller: Menggunakan kecerdasan buatan untuk merekayasa balik perangkat keras](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) — Catatan langsung penulis tentang pemindai dan kamera; menegaskan harness umum muncul setelah skrip khusus proyek. Hasil perangkat tunggal bersifat anekdotal dan tidak direplikasi secara independen oleh BIG CHANGE.
- [Repositori hw-harness pada commit 093afc5](https://github.com/cschalle/hw-harness) — README, alat, prasyarat Fedora/Windows, contoh alur kerja, dan catatan privasi; lisensi MIT diverifikasi dari LICENSE. Commit dipatok dalam audit sumber.
- [hw-harness: Metode](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) — Kondisi dasar, tangkapan berpasangan, pembacaan rekaman, serta pemeriksaan konfigurasi terpisah saat bus yang relevan tidak tersedia. Ditinjau pada commit 093afc5.
- [hw-harness: VM acuan Windows](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) — Prasyarat guest, passthrough, dan RDP/SSH, termasuk batas Windows Home; keputusan instalasi dan lisensi tetap bergantung pada pengguna. Ditinjau pada commit 093afc5.
- [hw-harness: Tetap dalam batas clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) — Batas pengamatan dan biner vendor proyek, pedoman asal-usul, serta kehati-hatian terhadap paket tak tepercaya; praktik rekayasa, bukan nasihat hukum. Ditinjau pada commit 093afc5.