Christian Schaller نے ایک غیر معاون فلم اسکینر کے Windows ڈرائیور کی USB پر بھیجی گئی چیزیں ریکارڈ کرنے کے بعد اس سے Linux میں قابلِ شناخت اسکین حاصل کیا۔ اپنے 15 اکتوبر کے بیان میں وہ بتاتے ہیں کہ ان کیپچرز کے تجزیے اور SANE بیک اینڈ کی تیاری میں Claude سے مدد لی۔ پہلے اسکین میں معیار کے مسائل باقی تھے؛ بعد میں انہوں نے بہت بہتر ڈرائیور کی اطلاع دی۔ یہ ایک ڈویلپر اور ایک اسکینر کے نتائج ہیں، اس بات کی آزادانہ طور پر دہرائی گئی پیمائش نہیں کہ AI کتنی بار ڈرائیور لکھ سکتا ہے۔

اس کے بعد Schaller نے hw-harness شائع کیا، جو MIT لائسنس کے تحت اسکرپٹس اور دستاویزات کا مجموعہ ہے اور ان کے طریقے کو عمومی شکل دیتا ہے۔ وہ واضح کہتے ہیں کہ اسکینر اور کیمرے کے منصوبوں میں خصوصی طور پر لکھا گیا کوڈ استعمال ہوا تھا، شائع شدہ harness کی موجودہ شکل نہیں۔ کسی غیر معاون USB ڈیوائس تک جسمانی رسائی رکھنے والے Linux ڈرائیور ڈویلپر کے لیے مفید کام، ’AI کو ریورس انجینئرنگ کرنے دیں‘ سے محدود ہے: سازندے کے کام کرنے والے ڈرائیور کے ساتھ ایک عمل کیپچر کریں، Linux ڈرائیور کے ساتھ وہی عمل کیپچر کریں، پھر پہلے بامعنی فرق کی تحقیق کریں۔

بڑی تبدیلی

  • کیا بدلا: Schaller نے ایسا قابلِ تکرار طریقہ مرتب کیا ہے جس میں Windows ڈیوائس کے کام کرتے سیشن اور Linux ڈرائیور کی کوشش کو میزبان کے ایک ہی USB ریکارڈر سے ریکارڈ کیا جاتا ہے۔ ان کے اسکینر کا نتیجہ دکھاتا ہے کہ یہ موازنہ کیوں مدد دے سکتا ہے، لیکن یہ اب بھی ایک ہی رپورٹ کردہ واقعہ ہے۔
  • یہ کیوں اہم ہے: ڈرائیور ڈویلپر لیبل والے ٹریس AI کوڈنگ معاون کو دے کر پروٹوکول کی ممکنہ وضاحت یا چھوٹا تشخیصی پروگرام تجویز کرنے کو کہہ سکتا ہے۔ کسی بھی تیار کردہ کوڈ کو قبول کرنے سے پہلے ڈویلپر کو اب بھی ہارڈویئر، کام کرنے والا حوالہ جاتی عمل اور براہِ راست ٹیسٹ درکار ہیں۔
  • کس بات پر نظر رکھیں: طریقہ اس بات پر منحصر ہے کہ ڈیوائس کی متعلقہ ٹریفک دیکھی جا سکتی ہے یا نہیں۔ اندرونی MIPI کیمرے کے لیے شائع شدہ harness اس کے بجائے Windows ڈیوائس کنفیگریشن اور ACPI کے معائنے کا راستہ اختیار کرتا ہے؛ USB ٹریس کی ہدایات ڈویلپر کی ضروری معلومات کھو دیں گی۔

کیپچر سے پہلے کیا چاہیے

منصوبے کی hw-harness README کہتی ہے کہ اسے Fedora پر تیار اور ٹیسٹ کیا گیا تھا۔ دستاویزی سیٹ اپ کے لیے libvirt/KVM، سازندے کا ڈرائیور چلانے والا Windows مہمان نظام، حقیقی USB passthrough، Linux میزبان پر usbmon سے کیپچر، اور موازنے کے لیے Linux ڈرائیور یا تشخیصی پروگرام درکار ہے۔ Windows 11 Pro میں harness کے RDP پر مبنی گرافیکل کنٹرول استعمال ہو سکتے ہیں۔ اس کی VM رہنمائی بتاتی ہے کہ Home مہمان نظام SSH استعمال کر سکتا ہے، مگر وہ RDP کنٹرول نہیں۔ ریپوزٹری میں Fedora پیکیجز اور گروپ کی اجازتیں درج ہیں؛ ڈیوائس جوڑنے سے پہلے حاصل کردہ ریویژن میں harness doctor چلا کر غائب اجزا تلاش کریں۔

استعمال کی اجازت والی Windows تنصیب اور سازندے کا سافٹ ویئر، عین وہی ڈیوائس، دہرایا جا سکنے والا عمل اور پیکٹ کیپچرز کے لیے جگہ تیار رکھیں۔ VM، ہارڈویئر تک رسائی، Windows اور اپنی منتخب AI سروس کا بجٹ رکھیں؛ ریپوزٹری پورے عمل کی کوئی مقررہ لاگت نہیں بتاتی۔ اسکرپٹس MIT لائسنس کے تحت ہیں، مگر اس سے Windows یا سازندے کے سافٹ ویئر کا لائسنس نہیں ملتا۔ جمع شدہ مواد استعمال یا تقسیم کرنے سے پہلے اپنے لائسنس کی شرائط اور لاگو ریورس انجینئرنگ قواعد دیکھیں۔

ہر ڈیوائس کے لیے الگ منصوبہ جاتی ڈائریکٹری استعمال کریں۔ README کے مطابق harness init کنفیگریشن اور نظرانداز کی جانے والی etc/ اور captures/ ڈائریکٹریاں بناتا ہے۔ README کی مثالیں نقل کرنے کے بجائے اپنی ڈیوائس کے مطابق VM کا نام اور USB سازندے/پروڈکٹ کی شناختیں درج کریں۔ winctl auth، harness iso اور دستاویزی مہمان ابتدائی سیٹ اپ Windows VM کا کنٹرول قائم کرتے ہیں؛ کیپچر سے پہلے winctl status کو ssh: ok دکھانا چاہیے۔ اسے منصوبے کا دستاویزی سیٹ اپ سمجھیں، BIG CHANGE کا چلایا ہوا سلسلہ نہیں۔

دونوں نظاموں پر ایک ہی عمل ملائیں

  1. بیس لائن اور Windows حوالہ ریکارڈ کریں۔ ریپوزٹری کی طریقے کی دستاویز پر عمل کریں: پہلے دیکھیں کہ فارغ حالت کی ٹریفک کیسی ہوتی ہے۔ اگر ابتدائی enumeration درکار ہو تو USB ڈیوائس مہمان کو دینے سے پہلے میزبان کیپچر شروع کریں۔ passthrough والی ڈیوائس پر سازندے کا Windows ڈرائیور چلائیں اور کسی مختصر، مخصوص عمل، جیسے بتائی گئی ریزولیوشن پر اسکین، کو لیبل دیں۔ usbcap بس کی ٹریفک کیپچر کرتا ہے اور ایک .meta ضمنی فائل میں ڈیوائس، بس پتہ، دورانیہ اور لیبل لکھتا ہے۔ میزبان کا کیپچر مقام USB passthrough سے نیچے ہے، اس لیے مہمان کے عمل کا مشاہدہ کر سکتا ہے۔
  2. Linux کا مماثل عمل ریکارڈ کریں۔ ڈیوائس میزبان کو واپس دیں اور Linux ڈرائیور کو انہی سیٹنگز اور اسی مادی چیز کے ساتھ وہی عمل کرتے ہوئے کیپچر کریں۔ مماثل Linux رن کے بغیر صرف حوالہ جاتی کیپچر یہ ثابت نہیں کر سکتا کہ ڈرائیور کے کس عمل میں فرق آیا۔ ریپوزٹری کا اسکینر کمانڈ مصنف کے سیٹ اپ کی مثال ہے، ہر ڈیوائس کے لیے مشترک کمانڈ نہیں۔
  3. موازنہ کریں اور ایک مفروضہ آزمائیں۔ دونوں ٹریس Wireshark میں یا طریقے کی دستاویز کے tshark فلٹرز سے پڑھیں۔ ابتدائی منتقلیاں، عمل سے پہلے اور بعد کی لکھائی، اسٹیٹس پولنگ اور bulk-transfer کی ٹائمنگ دیکھیں۔ ایک وقت میں ایک سیٹنگ، جیسے ریزولیوشن، بدل کر دیکھیں کہ کون سی منتقلی بدلتی ہے۔ AI معاون سے ممکنہ فرق بتانے اور اس کی بنیاد والے کیپچر اور فریم کا حوالہ دینے کو کہیں۔ پھر ڈرائیور میں محدود تبدیلی کریں یا تشخیصی پروگرام بنائیں اور حقیقی ہارڈویئر پر وہی عمل دہرائیں۔ ماڈل کے جواب میں بظاہر معقول وضاحت ملنا کامیابی کی علامت نہیں۔

فوری نتیجہ لیبل لگی دو کیپچر فائلیں اور پہلے بامعنی فرق کا بیان ہے۔ کامیاب مرمت کے لیے Linux ڈیوائس کو ڈویلپر کی اپنی جانچ میں مطلوبہ نتیجے کے ساتھ ارادہ کیا گیا عمل مستقل طور پر کرنا ہوگا۔ چند بائٹس کا مل جانا یا ایک جزوی تصویر بن جانا پورے ڈرائیور کا معیار ثابت نہیں کرتا۔ Schaller کے بیان میں پہلے قابلِ شناخت اسکین پر بھی مزید کام درکار تھا، جبکہ ان کے کام کے دوران مرکزی SANE منصوبے میں ان کے اسکینر کی معاونت الگ سے آئی۔

ٹریس کا موازنہ مشکل ہو تو عمل مختصر کریں اور تصدیق کریں کہ ڈیوائس، سیٹنگز اور کیپچر کی تہہ ایک جیسی ہیں۔ طریقہ ایک سوال کا جواب دینے والے چھوٹے کیپچرز اور ڈیوائس جوڑنے کا ایک بار کیپچر کرنے کی سفارش کرتا ہے۔ passthrough یا مہمان کنٹرول ناکام ہو تو خالی ٹریس کو ڈرائیور کی خرابی سمجھنے سے پہلے harness doctor، hostdev status اور VM سیٹ اپ رہنمائی استعمال کریں۔ اصل کیپچرز اور نوٹس رکھیں تاکہ مجوزہ رجسٹر مستقل قدر کو مشاہدہ کردہ فریم تک واپس جوڑا جا سکے۔

USB ٹریسنگ کی حد

اندرونی MIPI کیمرہ میزبان USB ریکارڈر کو وہی مفید ٹریفک نہیں دکھاتا۔ طریقے کی دستاویز اس کے بجائے Windows PnP خصوصیات، INF فائلوں، registry اندراجات اور ACPI ٹیبلز کے لیے winctl probe اور Linux کی جانب معائنے کے لیے hwdbg کا استعمال بتاتی ہے۔ Schaller کہتے ہیں کہ انہوں نے kernel اور libcamera پیچز کے ساتھ یہ مختلف راستہ اپنے لیپ ٹاپ کے کیمرے پر اپنایا؛ وہ نتائج بھی ان کے اپنے بیان سے ہیں۔ کیمرے کے نتیجے کو اس بات کے ثبوت کا بدل نہ بنائیں کہ USB کا چکر کسی دوسرے آلے پر کامیاب ہوا۔

تحقیق کو ڈیوائس کے مشاہدہ کردہ رویے اور اعلانیہ کنفیگریشن تک رکھیں۔ ریپوزٹری کی clean-room رہنمائی سازندے کی بائنریز کو disassemble کرنے یا ان کا کوڈ Linux ڈرائیور میں نقل کرنے کو خارج کرتی ہے۔ یہ خبردار بھی کرتی ہے کہ کیپچرز میں ڈیوائس کے سیریل نمبر آ سکتے ہیں اور منصوبے کی ڈائریکٹری میں نجی SSH کلید ہوتی ہے۔ ٹریس، ڈیوائس شناختوں اور مہمان فائلوں کو AI سروس کو دینے یا عوامی طور پر بانٹنے سے پہلے دیکھیں؛ کلیدیں اور خام کیپچرز source control سے باہر رکھیں۔ شائع شدہ ہدایات آزمانے کا ایک طریقہ دیتی ہیں۔ BIG CHANGE نے مقررہ ریویژن پر بلاگ اور ریپوزٹری دیکھی، مگر VM نہیں چلائی، ڈیوائس کیپچر نہیں کی اور بننے والے ڈرائیور کی توثیق نہیں کی۔

ذرائع اور مزید مطالعہ

  • Christian Schaller کا 15 اکتوبر کا بیان اسکینر اور لیپ ٹاپ پر ان کے کام، Claude سے منسوب کردار اور خصوصی اسکرپٹس کے بعد مشترک harness آنے کی وجہ بتاتا ہے۔ اسکینر کا نتیجہ ان کی اپنی رپورٹ ہے؛ اس مضمون میں آزادانہ طور پر نہیں دہرایا گیا۔
  • hw-harness ریپوزٹری ٹولز، Fedora اور Windows کی پیشگی ضروریات، مثال کے سیٹ اپ اور منصوبے کی رازداری کی تنبیہ بیان کرتی ہے۔ BIG CHANGE نے commit 093afc5c576c200f29b771d01624a327d0ff1806 دیکھا، جو 14 اکتوبر 2026 کا ہے؛ ریپوزٹری MIT لائسنس کے تحت ہے اور اس ریویژن کے بعد بدل سکتی ہے۔
  • طریقہ بیس لائن، حوالہ، Linux موازنہ اور دہرانے کا چکر، کیپچر کی احتیاطیں، USB ٹریس پڑھنا اور میزبان کو نظر آنے والی بس کے بغیر ڈیوائسز کے لیے الگ راستہ طے کرتا ہے۔
  • Windows حوالہ جاتی VM سیٹ اپ مہمان تک رسائی، USB passthrough اور RDP کنٹرول میں Windows Pro اور Home کا فرق بیان کرتا ہے۔ اپنی تنصیب کے لائسنس کی شرائط دیکھیں۔
  • Clean-room کی حدود منصوبے کی مشاہدے پر مبنی روایت، سازندے کی بائنریز سے متعلق حدود اور مستقل قدروں کے ماخذ کو درج کرنے کی ضرورت بیان کرتی ہیں۔ یہ منصوبے کی انجینئرنگ رہنمائی ہے، قانونی رائے نہیں۔