Um desenvolvedor da Red Hat conseguiu criar drivers Linux funcionais para hardware sem qualquer suporte oficial usando, essencialmente, um agente de inteligência artificial. Christian Schaller — figura conhecida no ecossistema Fedora e GNOME — detalhou em 15 de outubro de 2026 como recorreu ao Claude Code para fazer engenharia reversa de um scanner de negativos e da câmera MIPI de um notebook ThinkPad. O trabalho virou também uma ferramenta aberta para que qualquer pessoa repita o processo.

A conclusão de Schaller é direta: a IA não substitui o conhecimento do desenvolvedor, mas elimina o trabalho repetitivo que costuma travar projetos de suporte a hardware no Linux.

O scanner que não funcionava no Linux

Tudo começou com uma caixa de negativos antigos, herança de família. Ao comprar um scanner Plustek OpticFilm 8200i — escolhido justamente por ser listado como compatível com Linux —, Schaller descobriu que o fabricante havia trocado o chipset interno. O novo modelo usa o controlador Genesys GL128 (ID USB 07b3:1825), sem suporte no projeto SANE. O modelo antigo, de mesmo nome, usava o GL845 e já era atendido.

O desenvolvedor admite que travou. “Eu basicamente fiquei preso e não cheguei a lugar nenhum por muito tempo, e praticamente desisti do projeto por alguns meses”, escreveu em seu blog.

A virada: Uma VM Windows sob controle da IA

O ponto de inflexão veio de uma publicação no X de Tom Crider, conhecido na comunidade como Glorious Eggroll, que descrevia como havia consertado um driver de mouse dando a um agente de IA controle total sobre uma instância Windows para capturar os dados necessários.

Schaller colou o relato no Claude e pediu ajuda para montar um ambiente equivalente. A configuração final combinava:

• Uma máquina virtual KVM com Windows e o driver original do fabricante;
• O dispositivo físico repassado (passthrough) para dentro da VM;
• Captura do tráfego USB no host Linux, via usbmon, camada invisível para o convidado.

Com isso, a IA pôde executar digitalizações reais no Windows, registrar a comunicação exata com o hardware e comparar com o que o driver Linux em desenvolvimento produzia. “A combinação de poder rodar scans no Windows e capturar os dados USB enquanto isso acontecia fez maravilhas”, relatou.

Em poucas horas, Schaller obteve sua primeira digitalização funcional no Linux — com defeitos de qualidade, mas plenamente reconhecível. Dias depois, tinha um driver quase finalizado, incluindo suporte a varredura por infravermelho. Ironicamente, no intervalo entre a desistência e a retomada, outro desenvolvedor já havia enviado código ao SANE upstream. “Acontece às vezes”, brincou.

hw-harness: A metodologia transformada em ferramenta

Para que outros não precisem reinventar o processo, Schaller generalizou os scripts que usou no projeto hw-harness, um conjunto de ferramentas pensado para sessões com Claude ou Codex. O fluxo tem quatro etapas:

1. Gravar uma sessão de referência — rodar o driver do fabricante na VM Windows com o dispositivo real em passthrough;
2. Capturar por fora da VM — registrar o tráfego com usbmon no host Linux, abaixo da camada de passthrough;
3. Repetir a mesma operação no Linux com o driver próprio, capturando da mesma forma;
4. Comparar (diff) os dois traces — como vêm do mesmo instrumento, são diretamente comparáveis. As diferenças viram a lista de bugs do driver.

Para dispositivos sem barramento acessível — caso da câmera MIPI interna —, o harness recorre à inspeção do lado Windows: arquivos INF, dados de registro, tabelas ACPI e propriedades de dispositivo.

Schaller faz questão de destacar o aspecto legal e ético da abordagem: o método não copia código proprietário. Ele observa o comportamento do hardware e extrai apenas dados de configuração, de modo que cada constante do novo driver pode ser rastreada até algo efetivamente registrado.

Câmera MIPI do ThinkPad: Correções no kernel e no libcamera

Animado com o resultado, Schaller aplicou a mesma técnica para resolver problemas antigos da webcam de seu Lenovo ThinkPad X1 Carbon Gen 14 (Aura Edition). O equipamento usa um sensor Sony IMX471 atrás de um processador de imagem Intel IPU7. No Linux, as imagens saíam escuras, com vinheta pesada e forte tom amarelo-esverdeado.

O trabalho foi condensado no projeto mipi-fixes-x1-aura. Entre os problemas encontrados e corrigidos:

No driver do kernel (IMX471):

• Um bug de seleção de crop retornava erro antes de armazenar o retângulo, levando o libcamera a assumir o array de pixels completo;
• O registrador de padrão de teste (test pattern) estava declarado com a largura incorreta;
• O teto de ganho analógico era baixo demais, custando cerca de 1,8 stops de sensibilidade.

No ISP por software do libcamera:

• A correção de sombreamento de lente (lens shading) estava completamente ausente, deixando os cantos cerca de 2,7 stops mais escuros;
• As estatísticas de balanço de branco eram somadas na profundidade de bits nativa do sensor contra um nível de preto de 8 bits, distorcendo as cores — correção que vale para qualquer sensor RAW10/RAW12.

Os números medidos são expressivos: em teste controlado de baixa luminosidade, o brilho do quadro saltou de 31,1 para 90,9. A razão vermelho/verde passou de 0,890 para 1,047, e azul/verde de 0,672 para 0,823, aproximando-se de uma webcam USB de referência. O azul ainda fica cerca de 17% abaixo no escuro, o que Schaller atribui ao balanço de branco grey-world.

Os patches do kernel já foram enviados a Kate Hsuan, e os do libcamera estão em revisão por Wim Taymans. Pacotes RPM para Fedora 44 estão disponíveis na página de releases do projeto.

Negative Vibes: Um app GNOME em Rust para digitalizar filmes

Como “um driver sozinho não serve de muito se digitalizar negativos continuar sendo doloroso”, Schaller também criou o Negative Vibes, aplicativo GNOME escrito em Rust e distribuído via Flatpak, já com o backend do scanner embutido.

O app preserva o scan exatamente como entregue pelo hardware — 16 bits, linear, com o plano infravermelho — e aplica todas as demais transformações como camadas não destrutivas. Entre os recursos estão inversão de negativo em espaço de densidade com correção de base do filme e dye crosstalk, configurações por rolo com overrides por quadro, remoção de poeira por infravermelho e software, calibração IT8 via ArgyllCMS e exportação para TIFF, JPEG, PNG e DNG com perfis ICC e metadados.

O driver próprio de Schaller, inclusive, mostrou-se mais rápido que o upstream em resolução máxima (34,6 s contra 54,4 s) e suporta remoção de poeira por infravermelho, embora o backend genesys oficial ofereça mais passos de resolução. Ele mantém uma página interativa de comparação lado a lado e diz encarar seu projeto como prova de conceito: “espero que todos, inclusive eu, usem o driver upstream quando ele atingir a paridade”.

O que o experimento ensina

Schaller resume três aprendizados:

• Capturas de referência mudam o jogo. Dar à IA uma trace sabidamente boa para comparar com uma defeituosa transforma um vago “não funciona” em uma lista concreta de diferenças. No caso da câmera MIPI, manter uma webcam USB conectada para servir de comparação foi crítico.
• A IA é boa na parte tediosa. Decodificar capturas, escrever rotinas de verificação e cruzar constantes. “Eu ainda preciso ser quem segura o hardware físico.”
• O hardware real é o único juiz. Todas as afirmações foram validadas no scanner e no notebook reais.

Ele encerra com honestidade: não reivindica perfeição. “O scanner me dá digitalizações de aparência decente e a câmera MIPI está muito melhor do que antes. Estou feliz por ter conseguido mover o ponteiro, apesar de não ter o conhecimento aprofundado para esse tipo de trabalho.”

Por que isso importa para o futuro do Linux

O caso se insere em um movimento mais amplo de aproximação entre inteligência artificial e desenvolvimento do kernel. O próprio Linus Torvalds já foi noticiado trabalhando em melhorias no kernel com apoio do Claude Code, e há exemplos recentes de implementações clean room de softwares proprietários geradas com auxílio de IA.

O gargalo histórico do Linux no desktop sempre foi, em boa medida, o suporte a hardware — especialmente periféricos de fabricantes que não publicam documentação. Se agentes de IA conseguem reduzir drasticamente o custo de horas de análise de traces USB e registros proprietários, a tendência é que o número de dispositivos “órfãos” no Linux diminua. O hw-harness, por ser aberto e genérico, é a peça que pode transformar um caso isolado de sucesso em prática reproduzível pela comunidade.

---

Com informações do blog pessoal de Christian F.K. Schaller (GNOME/Fedora – Red Hat).