- A proposta move as sequências de inicialização opacas de telas MIPI-DSI para o espaço de usuário utilizando programas BPF.
- O objetivo é eliminar o gargalo entre a adoção rápida de telas por fabricantes (OEMs) e a demora histórica das distribuições Linux em enviar drivers atualizados.
- Implementado como um driver de ponte (bridge), o código não trava o sistema aguardando o script e já foi testado nas telas Touch Display 2 do Raspberry Pi.
O desenvolvedor Maxime Ripard enviou uma série de patches para a lista de discussão do subsistema Direct Rendering Manager (DRM) do Kernel Linux. A proposta introduz um driver de painel MIPI-DSI que utiliza programas BPF para executar as sequências de inicialização do hardware a partir do espaço de usuário (userspace).
O problema do ciclo de suporte e a abordagem com BPF
Painéis MIPI-DSI costumam exigir sequências de inicialização opacas e pouco documentadas, demandando a criação de um driver específico para praticamente cada modelo produzido. Segundo a documentação da proposta, isso cria um gargalo técnico entre fabricantes (OEMs), que frequentemente adotam novas telas na linha de produção para lidar com problemas de fornecimento, e as distribuições Linux, que podem levar anos para enviar um kernel atualizado com o driver correspondente.
Com a implementação via BPF inspirada no funcionamento do HID-BPF, os scripts de inicialização da tela podem ser distribuídos separadamente do Kernel Linux e gerenciados com um ciclo de vida independente. O desenvolvedor planeja que um componente em userspace, acionado pelo udev, seja responsável por identificar e carregar o programa BPF correto para o painel conectado ao dispositivo.
Implementação como bridge e testes no Raspberry Pi
O código atual está funcional e foi testado em telas Touch Display 2 de 5 e 7 polegadas do Raspberry Pi. No entanto, a implementação foge do padrão arquitetural típico do Kernel Linux de duas maneiras.
Primeiro, o driver não impede o carregamento do sistema enquanto o script não é acionado. Ele é sondado continuamente pelo Kernel Linux, mas só relata que um monitor está conectado após o registro do programa BPF. Essa decisão permite que outras saídas de vídeo do equipamento continuem funcionando normalmente e possibilita forçar a saída de vídeo caso o painel não exija inicialização ou durante sessões de depuração.
Segundo, o código foi submetido como um driver de ponte (bridge) em vez de um driver de painel (panel). Essa escolha foi necessária porque os drivers de painel atuais não possuem acesso ao callback de detecção (detect callback), uma etapa técnica obrigatória para que a verificação de registro do programa BPF funcione corretamente. A série de patches ainda passará por revisão da comunidade antes de ser integrada à árvore principal (mainline).
