Christian Schaller usou Claude Code e o comportamento de um driver do Windows como referência ao investigar suporte para Linux para o scanner de filmes Plustek OpticFilm 8200i. O trabalho mostra como a comparação entre o funcionamento do dispositivo nos dois sistemas pode orientar a criação de um driver; os tempos de digitalização relatados, porém, vêm de um único teste. The New Stack descreveu o projeto e atribuiu os resultados a Schaller.
Claude Code é um agente de programação que pode ser instalado no Linux. A ferramenta ajuda a desenvolver software; o suporte a cada dispositivo depende de um driver compatível. A documentação da Anthropic informa que o instalador nativo coloca o executável em ~/.local/bin/claude (perguntas frequentes da Claude Code). Esse caminho é do agente, não de um driver de hardware.
Como um driver do Windows ajudou a investigar o scanner
O desafio estava no chipset. Segundo o relato do The New Stack, unidades mais novas do Plustek OpticFilm 8200i usam o Genesys GL128, enquanto o suporte existente no SANE atendia ao Genesys GL845, usado em unidades mais antigas. Schaller recorreu ao comportamento do driver do Windows como referência para investigar a implementação no Linux.
A implementação atribuída a Schaller oferece digitalização colorida e em tons de cinza de 300 a 7.200 dpi — pontos por polegada —, remoção de poeira por infravermelho e ajustes de exposição para negativos densos. Em setembro de 2026, o suporte ao OpticFilm 8200i também entrou no SANE, segundo o The New Stack, com o trabalho de outro desenvolvedor.
O que faz o hw-harness
Schaller publicou o hw-harness, um projeto generalizado, licenciado sob MIT, para comparar o comportamento de dispositivos entre Windows e Linux. O fluxo descrito pelo The New Stack executa o driver do fabricante em uma máquina virtual KVM, com o dispositivo físico conectado à máquina virtual. Claude controla a sessão do Windows, enquanto o usbmon captura o tráfego USB no computador host com Linux. Depois, o dispositivo volta ao Linux para uma segunda execução, e os registros são comparados.
O projeto reúne ferramentas com tarefas diferentes: winctl controla a máquina virtual; usbcap captura o tráfego; hostdev alterna o dispositivo entre o host e a máquina virtual; e hwdbg auxilia a depuração no Linux. Scripts em PowerShell coletam descritores do dispositivo, entradas do registro, tabelas ACPI e arquivos INF.
O hw-harness publicado não é o conjunto exato de ferramentas usado nos projetos do scanner e da câmera. O The New Stack também informou que o projeto ainda não havia sido testado em uma ampla variedade de hardwares. Assim, o fluxo descreve uma maneira de comparar rastros e comportamentos, não uma garantia de compatibilidade universal.
O que os tempos do scanner permitem concluir
Na comparação de uma única digitalização em resolução máxima relatada por Schaller, sua implementação levou 34,6 segundos; a versão upstream do SANE levou 54,4 segundos. As duas resolveram o mesmo nível de detalhe a 3.600 dpi. A diferença corresponde a esse teste específico, não a uma medida de velocidade típica para outras digitalizações.
A investigação separada da câmera do ThinkPad
Schaller também investigou a câmera do Lenovo ThinkPad X1 Carbon Gen 14 Aura Edition, que usa o sensor Sony IMX471 e o sistema de imagem Intel IPU7. O trabalho recorreu a arquivos de configuração do Windows, dados do registro, tabelas ACPI e propriedades do dispositivo, além de uma webcam USB como referência.
Segundo os resultados atribuídos a Schaller pelo The New Stack, o valor de brilho de um quadro em baixa luz passou de 31,1 para 90,9 após as alterações. O canal azul ainda ficou cerca de 17% abaixo da referência da webcam. Na reportagem publicada em 17 de outubro de 2026, os conjuntos de alterações para o Linux kernel e para o libcamera ainda não haviam sido integrados.
Por que a experiência e o teste no dispositivo continuam importantes
Um relato separado de Dmitry Brant sobre o driver de fita ftape ajuda a contextualizar esse tipo de trabalho. Brant conta que modernizou o driver ao longo de duas noites, em várias iterações e com correções manuais. Ele já tinha experiência com C e módulos do kernel e testou o módulo em unidades de fita reais. A descrição em primeira pessoa de Brant mostra como conhecimento técnico e validação no hardware fizeram parte daquele projeto.
