Nakapaglabas si Christian Schaller ng makikilalang Linux scan mula sa isang film scanner na walang suporta matapos irekord ang ipinapadala ng Windows driver nito sa USB. Sa kaniyang salaysay noong Oktubre 15, inilarawan niya ang paggamit ng Claude upang tumulong sa pagsusuri ng mga capture at pagbuo ng SANE backend. May problema pa sa kalidad ang unang scan; kalaunan, iniulat niya ang mas mahusay na driver. Resulta ito ng isang developer at isang scanner, hindi independiyenteng inulit na sukatan kung gaano kadalas kayang sumulat ng driver ang AI.

Pagkatapos, inilathala ni Schaller ang hw-harness, isang koleksiyon ng mga script at dokumentasyong may MIT license na ginagawang pangkalahatan ang kaniyang paraan. Tahasan niyang sinabing gumamit ng pasadyang code ang mga proyekto ng scanner at camera, hindi ng kasalukuyang anyo ng inilathalang harness. Para sa Linux driver developer na may pisikal na access sa USB device na walang suporta, mas makitid ang kapaki-pakinabang na gawain kaysa ‘hayaan ang AI na mag-reverse engineer’: i-capture ang isang operasyon ng gumaganang vendor driver, i-capture ang parehong operasyon ng Linux driver at siyasatin ang unang makabuluhang pagkakaiba.

Ang malaking pagbabago

  • Ano ang nagbago: Binuo ni Schaller ang isang nauulit na paraan upang obserbahan ang gumaganang Windows device session at isang pagsubok ng Linux driver gamit ang parehong USB recorder sa host. Ipinapakita ng resulta ng scanner kung bakit maaaring makatulong ang paghahambing, ngunit nananatili itong iisang iniulat na kaso.
  • Bakit mahalaga: Maaaring ibigay ng driver developer sa AI coding assistant ang mga trace na may label at humiling ng paliwanag sa protocol o maliit na probe. Kailangan pa rin ang hardware, gumaganang reference operation at direktang pagsusubok bago tanggapin ang anumang nabuong code.
  • Ano ang dapat bantayan: Nakasalalay ang paraan sa kung nakikita ang mahalagang traffic ng device. Para sa internal MIPI camera, lumilipat ang inilathalang harness sa Windows device configuration at pagsusuri ng ACPI; mawawala sa USB trace procedure ang impormasyong kailangan ng developer.

Ano ang kailangan bago mag-capture

Ayon sa README ng hw-harness, binuo at sinubukan ito sa Fedora. Kailangan sa dokumentadong setup ang libvirt/KVM, Windows guest na nagpapatakbo ng vendor driver, totoong USB passthrough, usbmon capture sa Linux host at Linux driver o probe na paghahambingan. Pinapagana ng Windows 11 Pro ang mga GUI control ng harness na nakabatay sa RDP. Ayon sa gabay sa VM, maaari pa ring gumamit ng SSH ang Home guest, ngunit hindi ng mga RDP control na iyon. Nakalista sa repository ang mga Fedora package at pahintulot ng grupo; patakbuhin ang harness doctor sa na-checkout na revision upang makita ang kulang bago ikonekta ang device.

Maghanda ng pinahihintulutang Windows installation at vendor software, eksaktong device, nauulit na operasyon at espasyo para sa packet capture. Maglaan para sa VM, hardware access, Windows at napiling AI service; walang nakatakdang kabuuang gastos sa repository. MIT licensed ang mga script, ngunit hindi nito ibinibigay ang lisensiya ng Windows o vendor software. Suriin ang sariling license terms at angkop na mga tuntunin sa reverse engineering bago gamitin o ipamahagi ang nakalap.

Gumamit ng hiwalay na project directory para sa bawat device. Ayon sa README, ang harness init ay lumilikha ng configuration at ng mga directory na hindi isinasama sa version control na etc/ at captures/. Ilagay ang VM name at USB vendor/product ID mula sa device sa halip na kopyahin ang mga halimbawang halaga sa README. Ang winctl auth, harness iso at dokumentadong paunang setup ng guest ang nagbibigay ng kontrol sa Windows VM; dapat mag-ulat ang winctl status ng ssh: ok bago ang capture. Dokumentadong setup ito ng proyekto, hindi sunod-sunod na hakbang na pinatakbo ng BIG CHANGE.

Itugma ang isang operasyon sa dalawang sistema

  1. Irekord ang baseline at Windows reference. Sundin ang dokumento ng pamamaraan sa repository: alamin muna ang anyo ng idle traffic. Simulan ang host capture bago ibigay ang USB device sa guest kung kailangan ang paunang enumeration nito. Patakbuhin ang Windows driver ng vendor sa device na naka-passthrough at lagyan ng label ang isang maikli at tiyak na aksiyon, gaya ng scan sa nakasaad na resolution. Ang usbcap ay nagka-capture ng bus at sumusulat ng .meta sidecar file na may device, bus address, tagal at label. Nasa ilalim ng USB passthrough ang capture point ng host, kaya nakikita nito ang operasyon ng guest.
  2. Irekord ang katumbas na operasyon sa Linux. Ibalik ang device sa host at i-capture ang Linux driver na gumagawa ng parehong operasyon, gamit ang parehong setting at pisikal na materyal. Hindi matutukoy ng reference capture na walang katumbas na Linux run kung aling aksiyon ng driver ang lumihis. Halimbawa para sa setup ng may-akda ang scanner command sa repository, hindi unibersal na command para sa lahat ng device.
  3. Ihambing at subukan ang isang palagay. Basahin ang dalawang trace sa Wireshark o gamit ang mga tshark filter ng dokumento ng pamamaraan. Suriin ang initialization transfer, mga write bago at pagkatapos ng aksiyon, status polling at timing ng bulk transfer. Baguhin ang isang setting lamang bawat pagkakataon, gaya ng resolution, upang makita kung aling transfer ang nagbabago. Hilingin sa AI assistant na tukuyin ang posibleng pagkakaiba at banggitin ang capture at frame na batayan nito. Pagkatapos, gumawa ng limitadong pagbabago sa driver o probe at ulitin ang parehong operasyon sa totoong hardware. Hindi tanda ng tagumpay ang kapani-paniwalang paliwanag ng modelo.

Ang agarang resulta ay magkaparis na capture file na may label at paliwanag sa unang makabuluhang pagkakaiba. Sa matagumpay na pag-aayos, kailangang palaging magawa ng Linux device ang nilalayong operasyon at inaasahang output sa sariling pagsusuri ng developer. Hindi pinatutunayan ng ilang magkatugmang byte o isang bahagyang larawan ang buong kalidad ng driver. Sa salaysay ni Schaller, kailangan pa ng trabaho ang unang makikilalang scan, at hiwalay na lumitaw ang upstream SANE support para sa kaniyang scanner habang ginagawa niya ito.

Kung mahirap ihambing ang mga trace, paikliin ang operasyon at tiyaking tugma ang device, setting at capture layer. Iminumungkahi ng pamamaraan ang maliliit na capture na sumasagot sa isang tanong at isang capture ng pagkakabit ng device. Kung mabigo ang passthrough o guest control, gamitin ang harness doctor, hostdev status at ang gabay sa VM setup bago ituring na problema ng driver ang walang lamang trace. Panatilihin ang orihinal na capture at mga tala upang masundan ang iminungkahing register constant pabalik sa naobserbahang frame.

Kung saan nagtatapos ang USB tracing

Hindi inilalantad ng internal MIPI camera ang parehong kapaki-pakinabang na traffic sa host USB recorder. Sa halip, inilalarawan ng dokumento ng pamamaraan ang winctl probe para sa Windows PnP property, INF file, registry entry at ACPI table, kasama ang pagsusuri sa Linux sa pamamagitan ng hwdbg. Iniulat ni Schaller na ginamit ang ibang rutang ito sa laptop camera, na may kernel at libcamera patch; mula rin sa kaniyang salaysay ang mga resultang iyon. Huwag ituring ang resulta ng camera bilang ebidensiyang gumana ang USB loop sa ibang device.

Ituon ang pagsisiyasat sa naobserbahang kilos ng device at declarative configuration. Ang gabay sa clean-room ng repository ay hindi nagsasama ng pag-disassemble ng vendor binary o pagkopya ng code nito sa Linux driver. Nagbababala rin na maaaring may serial number ng device sa capture at may pribadong SSH key sa project directory. Suriin ang trace, device identifier at guest file bago ibigay sa AI service o ibahagi sa publiko; huwag isama sa source control ang mga key at raw capture. Nagtatakda ang inilathalang mga tagubilin ng paraang maaaring subukan. Sinuri ng BIG CHANGE ang blog at repository sa nakapirming revision ngunit hindi nagpatakbo ng VM, nag-capture ng device o nagpatunay ng nabuong driver.

Mga sanggunian at karagdagang babasahin

  • Ang salaysay ni Christian Schaller noong Oktubre 15 ay nagpapaliwanag ng kaniyang scanner at laptop work, papel na iniuugnay niya sa Claude at kung bakit sumunod ang shared harness sa mga pasadyang script. Kaniyang ulat ang resulta ng scanner, nang walang independiyenteng pag-uulit sa artikulong ito.
  • Ang repository ng hw-harness ay naglalarawan ng mga tool, Fedora at Windows prerequisite, halimbawang setup at babala sa privacy. Sinuri ng BIG CHANGE ang commit na 093afc5c576c200f29b771d01624a327d0ff1806 mula Oktubre 14, 2026; MIT licensed ang repository at maaaring magbago pagkatapos ng revision na iyon.
  • Ang pamamaraan ay nagtatakda ng baseline, reference, Linux comparison at repeat loop, maingat na paghawak ng capture, pagbasa ng USB trace at hiwalay na ruta para sa device na walang bus na nakikita ng host.
  • Ang setup ng Windows reference VM ay tumatalakay sa guest access, USB passthrough at pagkakaiba ng Windows Pro at Home para sa RDP control. Tingnan ang license terms ng sariling installation.
  • Ang mga hangganan ng clean-room ay naglalahad ng gawaing batay sa obserbasyon, mga limitasyon sa vendor binary at pangangailangang itala ang pinagmulan ng constant. Gabay sa engineering ito ng proyekto, hindi legal na opinyon.