Windows ड्रायव्हर USB वर काय पाठवतो ते नोंदवल्यानंतर Christian Schaller यांना समर्थित नसलेल्या फिल्म स्कॅनरमधून Linux वर ओळखता येण्याजोगा स्कॅन मिळाला. त्यांच्या 15 ऑक्टोबरच्या अनुभवकथनात त्यांनी त्या कॅप्चरचे विश्लेषण आणि SANE बॅकएंड तयार करण्यासाठी Claude ची मदत घेतल्याचे म्हटले आहे. पहिल्या स्कॅनमध्ये तरीही दर्जाच्या समस्या होत्या; नंतर त्यांनी खूप सुधारलेल्या ड्रायव्हरची माहिती दिली. हे एका विकसकाचे आणि एका स्कॅनरचे निष्कर्ष आहेत, AI किती वेळा ड्रायव्हर लिहू शकते याचे स्वतंत्रपणे पुनरुत्पादित मोजमाप नाही.
Schaller यांनी नंतर hw-harness प्रसिद्ध केले. त्यांच्या पद्धतीला सर्वसाधारण रूप देणाऱ्या स्क्रिप्ट आणि दस्तऐवजांचा हा MIT-परवानाधारक संच आहे. स्कॅनर आणि कॅमेरा प्रकल्पांत खास लिहिलेला कोड वापरला, सध्याच्या स्वरूपातील प्रकाशित harness नव्हे, असे ते स्पष्ट सांगतात. समर्थित नसलेल्या USB उपकरणाचा प्रत्यक्ष ताबा असलेल्या Linux ड्रायव्हर विकसकासाठी काम ‘AI कडून रिव्हर्स इंजिनिअरिंग करून घ्या’ यापेक्षा मर्यादित आहे: चालणाऱ्या उत्पादक-ड्रायव्हरची एक कृती कॅप्चर करा, Linux ड्रायव्हरची तीच कृती कॅप्चर करा आणि पहिला अर्थपूर्ण फरक तपासा.
मोठा बदल
- काय बदलले: चालणारे Windows उपकरण सत्र आणि Linux ड्रायव्हरचा प्रयत्न एकाच होस्टवरील USB नोंदकाखाली पाहण्याची पुनरावृत्ती करता येणारी पद्धत Schaller यांनी एकत्र दिली आहे. स्कॅनरचा निकाल तुलना का मदत करू शकते ते दाखवतो, पण तो एकच नोंदवलेला प्रसंग आहे.
- हे महत्त्वाचे का: ड्रायव्हर विकसक नाव दिलेल्या नोंदी AI कोडिंग सहाय्यकाला देऊन प्रोटोकॉलचे स्पष्टीकरण किंवा लहान चाचणी प्रोग्राम सुचवायला सांगू शकतो. तयार केलेला कोड स्वीकारण्याआधी हार्डवेअर, चालणारी संदर्भ कृती आणि प्रत्यक्ष चाचण्या तरीही आवश्यक आहेत.
- कशाकडे लक्ष द्यावे: संबंधित उपकरणाचा ट्रॅफिक दिसू शकतो का, यावर पद्धत अवलंबून आहे. अंतर्गत MIPI कॅमेरासाठी प्रकाशित harness त्याऐवजी Windows उपकरण कॉन्फिगरेशन आणि ACPI तपासणी वापरते; USB नोंदींच्या प्रक्रियेत विकसकाला लागणारी माहिती सुटेल.
कॅप्चरपूर्वी काय लागेल
प्रकल्पाचे hw-harness README म्हणते की तो Fedora वर विकसित आणि तपासला गेला. दस्तऐवजी मांडणीत libvirt/KVM, उत्पादकाचा ड्रायव्हर चालवणारा Windows गेस्ट, खरे USB पासथ्रू, Linux होस्टवर usbmon कॅप्चर आणि तुलना करण्यासाठी Linux ड्रायव्हर किंवा तपासणी प्रोग्राम लागतो. Windows 11 Pro मुळे harness ची RDP-आधारित GUI नियंत्रणे वापरता येतात. VM मार्गदर्शकात Home गेस्ट SSH वापरू शकतो, पण ती RDP नियंत्रणे वापरू शकत नाही, असे म्हटले आहे. रिपॉझिटरीत Fedora पॅकेज आणि गट परवानग्या दिल्या आहेत; उपकरण जोडण्याआधी चेकआउट केलेल्या आवृत्तीत harness doctor चालवून उणिवा शोधा.
परवानगी असलेले Windows इंस्टॉलेशन आणि उत्पादकाचे सॉफ्टवेअर, नेमके उपकरण, पुन्हा करता येणारी कृती आणि पॅकेट कॅप्चरसाठी जागा तयार ठेवा. VM, हार्डवेअरचा प्रवेश, Windows आणि निवडलेल्या AI सेवेच्या खर्चाची तरतूद करा; रिपॉझिटरी एकूण निश्चित खर्च सांगत नाही. स्क्रिप्ट MIT परवान्याखाली आहेत, पण त्यामुळे Windows किंवा उत्पादक-सॉफ्टवेअरचा परवाना मिळत नाही. गोळा केलेली सामग्री वापरण्याआधी किंवा वाटण्याआधी स्वतःच्या परवान्यांच्या अटी आणि लागू रिव्हर्स-इंजिनिअरिंग नियम तपासा.
प्रत्येक उपकरणासाठी वेगळी प्रकल्प डिरेक्टरी वापरा. README नुसार harness init कॉन्फिगरेशन आणि आवृत्ती नियंत्रणातून वगळलेल्या etc/ व captures/ डिरेक्टरी तयार करते. README मधील उदाहरणे न उतरवता उपकरणाचे VM नाव आणि USB उत्पादक/उत्पादन ID भरा. winctl auth, harness iso आणि दस्तऐवजांतील गेस्टची सुरुवातीची मांडणी Windows VM चे नियंत्रण प्रस्थापित करतात; कॅप्चरपूर्वी winctl status ने ssh: ok दाखवायला हवे. ही प्रकल्पाची दस्तऐवजी मांडणी आहे, BIG CHANGE ने करून पाहिलेला क्रम नाही.
दोन्ही प्रणालींवर एकच कृती जुळवा
- मूळ निष्क्रिय स्थिती आणि Windows संदर्भ नोंदवा. रिपॉझिटरीतील पद्धतीचा दस्तऐवज पाळा: आधी निष्क्रिय ट्रॅफिक कसा दिसतो ते समजून घ्या. उपकरणाची सुरुवातीची ओळख नोंदवायची असेल तर USB उपकरण गेस्टकडे देण्याआधी होस्ट कॅप्चर सुरू करा. पासथ्रू केलेल्या उपकरणावर उत्पादकाचा Windows ड्रायव्हर चालवा आणि ठरावीक रिझोल्यूशनवरील स्कॅनसारखी छोटी, नेमकी कृती लेबल करा.
usbcapबस कॅप्चर करून उपकरण, बस पत्ता, कालावधी आणि लेबल असलेली.metaपूरक फाइल लिहिते. होस्टचा कॅप्चर बिंदू USB पासथ्रूच्या खाली असल्याने गेस्टची कृती पाहता येते. - त्याच्याशी जुळणारी Linux कृती नोंदवा. उपकरण पुन्हा होस्टकडे द्या आणि तीच सेटिंग व तीच भौतिक सामग्री वापरून Linux ड्रायव्हरची तीच कृती कॅप्चर करा. जुळणारा Linux प्रयत्न नसलेला संदर्भ कॅप्चर ड्रायव्हरच्या कोणत्या कृतीत फरक झाला हे सांगू शकत नाही. रिपॉझिटरीतील स्कॅनर कमांड लेखकाच्या मांडणीचे उदाहरण आहे, सर्व उपकरणांसाठी सार्वत्रिक कमांड नाही.
- तुलना करा आणि एक गृहीतक तपासा. दोन्ही नोंदी Wireshark मध्ये किंवा पद्धतीच्या दस्तऐवजातील
tsharkफिल्टरने वाचा. प्रारंभिक हस्तांतरे, कृतीच्या आधी-पुढचे लेखन, स्थितीचे पोलिंग आणि बल्क हस्तांतरणाची वेळ तपासा. कोणते हस्तांतरण बदलते ते पाहण्यासाठी रिझोल्यूशनसारखी एकच सेटिंग एका वेळी बदला. AI सहाय्यकाला संभाव्य फरक ओळखून त्यामागचे कॅप्चर व फ्रेम नमूद करायला सांगा. नंतर ड्रायव्हरमध्ये मर्यादित बदल किंवा लहान तपासणी प्रोग्राम करून प्रत्यक्ष हार्डवेअरवर तीच कृती पुन्हा करा. मॉडेलच्या उत्तरातील पटण्याजोगे स्पष्टीकरण म्हणजे यश नव्हे.
तातडीचा परिणाम म्हणजे नाव दिलेली कॅप्चर फाइलची जोडी आणि पहिल्या अर्थपूर्ण फरकाचे वर्णन. यशस्वी दुरुस्तीसाठी विकसकाच्या स्वतःच्या तपासण्यांत Linux उपकरणाने अपेक्षित कृती सातत्याने आणि अपेक्षित निष्पत्तीसह करायला हवी. काही बाइट जुळणे किंवा एक अपूर्ण प्रतिमा मिळणे संपूर्ण ड्रायव्हरचा दर्जा सिद्ध करत नाही. Schaller यांच्या कथनात पहिल्या ओळखण्याजोग्या स्कॅननंतरही काम उरले होते; ते काम करत असतानाच त्यांच्या स्कॅनरचे अपस्ट्रीम SANE समर्थन स्वतंत्रपणे आले.
नोंदींची तुलना कठीण असल्यास कृती लहान करा आणि उपकरण, सेटिंग व कॅप्चरचा स्तर जुळत असल्याची खात्री करा. एका प्रश्नाचे उत्तर देणारे छोटे कॅप्चर आणि उपकरण जोडण्याचे एकदाचे कॅप्चर पद्धत सुचवते. पासथ्रू किंवा गेस्ट नियंत्रण अयशस्वी झाल्यास harness doctor, hostdev status आणि VM सेटअप मार्गदर्शक वापरून आधी तपास करा; त्यानंतरच रिकामी नोंद ड्रायव्हरच्या दोषामुळे आहे का ते ठरवा. मूळ कॅप्चर आणि टिपणे जतन करा, म्हणजे सुचवलेला रजिस्टर स्थिरांक दिसलेल्या फ्रेमपर्यंत मागोवा घेता येईल.
USB नोंदणी कुठे थांबते
अंतर्गत MIPI कॅमेरा होस्ट USB नोंदकाला तोच उपयुक्त ट्रॅफिक दाखवत नाही. त्याऐवजी पद्धतीचा दस्तऐवज Windows PnP गुणधर्म, INF फाइल, रजिस्ट्री नोंदी आणि ACPI तक्त्यांसाठी winctl probe तसेच Linux बाजूच्या तपासणीसाठी hwdbg वापरण्याचे वर्णन करतो. Schaller यांनी लॅपटॉप कॅमेरासाठी ही वेगळी वाट वापरून कर्नल आणि libcamera पॅच केल्याचे म्हटले आहे; हे निकालही त्यांच्या कथनावर आधारित आहेत. दुसऱ्या उपकरणावर USB प्रक्रिया यशस्वी ठरल्याचा पुरावा म्हणून कॅमेराचा निकाल वापरू नका.
तपास उपकरणाच्या दिसलेल्या वर्तनावर आणि घोषित कॉन्फिगरेशनवर केंद्रित ठेवा. रिपॉझिटरीतील क्लीन-रूम मार्गदर्शक उत्पादकांच्या बायनरीचे डिसअसेम्बलिंग किंवा त्यांचा कोड Linux ड्रायव्हरमध्ये कॉपी करणे वगळतो. कॅप्चरमध्ये उपकरणांचे अनुक्रमांक असू शकतात आणि प्रकल्प डिरेक्टरीत खासगी SSH की असते, असाही इशारा देतो. AI सेवेला देण्याआधी किंवा सार्वजनिक वाटण्याआधी नोंदी, उपकरण ओळखचिन्हे आणि गेस्ट फाइल तपासा; की व मूळ कॅप्चर आवृत्ती नियंत्रणाबाहेर ठेवा. प्रकाशित सूचना वापरून पाहण्याची पद्धत देतात. BIG CHANGE ने ब्लॉग व निश्चित आवृत्तीची रिपॉझिटरी तपासली, पण VM चालवला नाही, उपकरण कॅप्चर केले नाही किंवा तयार झालेल्या ड्रायव्हरची पडताळणी केली नाही.
स्रोत आणि पुढील वाचन
- Christian Schaller यांचे 15 ऑक्टोबरचे कथन स्कॅनर व लॅपटॉपवरील काम, Claude ला त्यांनी दिलेली भूमिका आणि सामायिक harness खास स्क्रिप्टनंतर का आला हे सांगते. स्कॅनरचा निकाल त्यांचा अहवाल आहे; या लेखात स्वतंत्रपणे पुनरुत्पादित केलेला नाही.
- hw-harness रिपॉझिटरी साधने, Fedora व Windows पूर्वअटी, मांडणीचे उदाहरण आणि प्रकल्पाचा गोपनीयतेचा इशारा देते. BIG CHANGE ने 14 ऑक्टोबर 2026 चा कमिट
093afc5c576c200f29b771d01624a327d0ff1806तपासला; रिपॉझिटरी MIT परवानाधारक असून त्या आवृत्तीनंतर बदलू शकते. - पद्धत मूलस्थिती, संदर्भ, Linux तुलना व पुनरावृत्तीचे चक्र, कॅप्चरची निगा, USB नोंदी वाचणे आणि होस्टला बस दिसत नसलेल्या उपकरणांची वेगळी वाट स्पष्ट करते.
- Windows संदर्भ VM ची मांडणी गेस्ट प्रवेश, USB पासथ्रू आणि RDP नियंत्रणांसाठी Windows Pro व Home मधील फरक सांगते. स्वतःच्या इंस्टॉलेशनच्या परवान्याच्या अटी तपासा.
- क्लीन-रूमच्या सीमा प्रकल्पाची निरीक्षणाधारित पद्धत, उत्पादक बायनरीबाबतच्या मर्यादा आणि स्थिरांकांचे मूळ नोंदवण्याची गरज स्पष्ट करतात. हे प्रकल्पाचे अभियांत्रिकी मार्गदर्शन आहे, कायदेशीर मत नाही.
