segunda-feira, 28 de maio de 2018
Ainda vai ser difícil obter o driver OpenChrome VIA KMS no kernel Linux
Confira!!
O esforço de muitos anos no driver DRM / KMS VIA "OpenChrome" de código aberto pode culminar em entrar no kernel principal do Linux nos próximos ciclos do kernel, mas ainda há muito trabalho para que isso aconteça.
Kevin Brace, que é em grande parte o único colaborador (independente) que saiu do projeto OpenChrome para fornecer suporte de driver de código aberto Linux para hardware gráfico VIA x86 envelhecido, espera vê-lo em breve para obter este driver como principal.
Ele tem trabalhado recentemente na correção de alguns bugs e nos últimos meses tem se concentrado no suporte ao kernel. Mas se esse driver está sendo mainlined, o corte inicial no kernel não suportará qualquer ainda a ser desenvolvido driver de OpenGL de espaço de usuário Gallium3D e muito menos qualquer suporte 2D.
Neste fim de semana, Brace enviou outra mensagem da lista de discussão do kernel sobre suas idéias principais . Ele espera colocá-lo em destaque nos "próximos um ou dois ciclos de desenvolvimento do kernel do Linux" para este driver com mais de 7 anos.
Entre os problemas em aberto estão se o driver OpenChrome DRM precisa passar das interfaces KMS "legadas" para o suporte à configuração de modo atômico, o código de aceleração básico dentro do código DRM não foi concluído e pode precisar ser removido e outros assuntos abertos .
O mantenedor do subsistema DRM, David Airlie, respondeu que ele não insistirá no estabelecimento do modo atômico como requisito para a fusão, mas se outros desenvolvedores upstream insistirem nele e forem necessários para revisão, ele obedeceria aos desejos dos outros. Além disso, o código de aceleração inacabado precisaria ser removido para mesclagem, bem como a remoção do código para chamadas personalizadas da API libdrm. David também comentou que se uma revisão inicial pode ser feita por outros, o driver OpenChrome DRM pode ser permitido em "DRM staging" enquanto resolve outros assuntos em aberto.
Certamente é tarde demais para fazer o driver ser revisado e preparado para o Linux 4.18, de modo que seria o Linux 4.19 ou Linux 5.0 antes de possivelmente ver o código em um estado pronto para encontrar o caminho para o kernel Linux principal, se tudo correr bem. Mas se a configuração do modo atômico é considerada necessária, isso poderia empurrar o esforço de volta por vários outros lançamentos.
Fonte
Até a próxima!!
Marcadores: Linux, Android, Segurança
#dev linux,
#Linux,
#Notícia
Assinar:
Postar comentários (Atom)
Nenhum comentário:
Postar um comentário