Como sabemos, o novo kernel Linux 5.8 foi lançado no último domingo. É um dos maiores lançamentos de todos os tempos. Sobre isso, você pode encontrar as alterações mais importantes para esta versão nos sempre excelentes artigos do LWN.net – parte 1 e parte 2.
Segundo o próprio Linus, o lançamento da versão 5.8 é grande. Enquanto isso, a Collabora contribuiu modestamente para este lançamento massivo. Segundo um comunicado, o Linux 5.8 marca as maiores e mais significativas contribuições da Collabora até o momento.
Todos na Collabora ficaram impressionados com os esforços reunidos pelos nossos desenvolvedores de Kernel. Trabalhar diretamente a montante, contribuir com o kernel do Linux há muito tempo é um objetivo fundamental da Collabora como organização. Na última década, aumentamos nossa participação nesse esforço essencial que é o Linux.
A capacidade de uma consultoria de software relativamente pequena, como a Collabora, contribuir com esse nível demonstra uma melhoria fantástica na mentalidade dos fornecedores quando se trata de trabalhar com o Open First (daí o slogan da Collabora). Fornecer Suporte da linha principal pronto para uso o mais cedo possível está realmente se tornando uma prioridade para todos os nossos clientes e agradecemos ainda mais por isso.
Kernel 5.8 traz atualizações importantes para os SoCs RockChip e MediaTek
Contribuições do Rockchip
A Collabora é um apoiador muito ativo do Rockchip SoC, usado em dispositivos como Chromebooks, laptops, várias placas de desenvolvimento e outros dispositivos. Contribuímos especialmente com gráficos (drivers do Mali, Panfrost) e multimídia. Aqui está a lista de contribuições para esta plataforma:
Suporte DRM AFBC para Rockchip
O AFBC (Arm Frame Buffer Compression) é um recurso de hardware, disponível em vários ARM SoCs, que reduz a largura de banda da memória usada pela compactação de buffers enviados ao monitor. Esse recurso é muito importante para melhorar o uso de energia e permite que os drivers do espaço do usuário executem uma renderização mais eficiente, reduzindo o número de cópias do buffer de exibição. Para esta versão, Andrzej Pietrasiewicz adicionou suporte ao AFBC no Rockchip. Veja a postagem no blog para obter explicações detalhadas.
Upstreaming do driver Rockchip VDEC
Continuando nosso trabalho em aceleradores de codec, Boris Brezillon contribuiu com uma série de upstream do driver Rockchip Video Decoder (rkvdec). Parte deste trabalho inclui mover o manuseio do DPB H.264 para o núcleo, para que possa ser reutilizado por outros drivers.
Este driver suporta um bloco IP de codec específico para Rockchip que pode ser encontrado em SoCs Rockchip, como RK3399, RK3326 e PX30.
Por enquanto, apenas o H.264 é suportado no driver rkvdec. Atualmente, o suporte ao perfil H.264 High-10 está sendo discutido pela comunidade. Além disso, VP9 e HEVC devem ser adicionados em breve.
Este driver acelerador implementa a recém-introduzida interface decodificador de vídeo sem memória de memória em memória. Sendo uma nova interface, é necessário algum suporte do lado do aplicativo. Nicolas Dufresne adicionou recentemente suporte a isso no GStreamer . Ele apresentou recentemente o histórico de suporte a codecs no kernel no ELCE 2020.
Destino do progresso dos drivers da Rockchip Camera
O driver do ISK da câmera RK3399 (rkisp1) alcançou a área de preparação do kernel da linha principal na v5.6. Com o objetivo de melhorar a qualidade do código e fornecer um driver estável para os usuários, um esforço conjunto contínuo entre Helen Koike e eu (Dafna Hirschfeld) está sendo feito para destocar o driver rkisp1 e o driver dphy correspondente phy-rockchip-dphy-rx0. Para esta versão do kernel, avançamos várias etapas e estamos nos aproximando do objetivo.
Algumas correções principais (conjunto) s:
- adicionando suporte para formatos RGB
- destaging rockchip dphy rx0 ligações
- corrigindo o uso da API fwnode
O driver já é suportado pelo projeto libcamera, que permite que os aplicativos funcionem sobre uma infinidade de dispositivos diferentes sem se preocupar com o hardware subjacente.
O driver rkisp1exporta uma API que permite que o espaço do usuário implemente algoritmos de aprimoramento de imagem como 3A. Uma implementação de código aberto foi adicionada recentemente na libcamera para o Raspberry Pi. Esperamos que seja tornado genérico no futuro, suportando dispositivos Rockchip e vários outros.
Retrabalho das permissões do mestre DRM
O subsistema DRM fornece os meios para gerenciar e utilizar saídas de vídeo (modo definido) e dispositivos de renderização. Para impedir que aplicativos mal-intencionados alterem a resolução de uma tela ou desabilitem tudo juntos, existe o conceito de DRM_MASTER. Isso permite que um único programa gerencie quais processos têm permissão para executar essas tarefas.
Nas plataformas com systemd, o serviço systemd-logind é aquele com a função DRM_MASTER, orquestrando quais processos têm permissão para executar operações de modo definido. No entanto, há casos em que systemd não está disponível ou o servidor de gráficos (Xorg ou um compositor de Wayland) não pode usá-lo por vários motivos.
Emil Velikov reformulou os ioctls SET/DROP_MASTER, permitindo que um processo de espaço do usuário com privilégio DRM_MASTER revogue seu privilégio e recupere-o facilmente. Anteriormente, o programa tinha que ser executado como root ou ter seu bit setuid definido (como visto no Xorg e no weston-launch) apenas para esse fim.
Com o adesivo, esse requisito artificial foi levantado. Efetivamente, isso faz o Xorg funcionar (em vez de travar totalmente) em alguns casos de esquina, enquanto permite que as distribuições retirem o sinalizador setuid do Xorg, weston-launch e outros. Isso melhora a segurança, reduzindo o número de programas em execução com privilégios de root.
Subsys MTD – convertendo código legado em nova API
O Linux é conhecido por seu bom suporte a hardware antigo, sendo a política “se ainda houver um usuário preocupado com um hardware específico, o suporte não deve ser descartado”. Isso é ótimo para os usuários, mas às vezes atrapalha a refatoração de subsistemas, deixando os mantenedores com duas opções:
- Continuar apoiando as APIs/interfaces antigas e adicionar uma nova por cima;
- Drivers de patch dos quais eles não sabem nada, não têm hardware para testar e cujos usuários são difíceis de encontrar e/ou demoram a responder.
O MTD é bastante antigo e, como resultado, carrega muita história, com nada menos que três interfaces diferentes expostas aos drivers. Esse é o resultado de buscar repetidamente a opção 1, sem forçar os mantenedores de driver a converter seus drivers para a API mais recente.
Essa política levou a uma situação em que toda evolução das partes internas do subsistema é uma operação dolorosa, exigindo cuidados extras para não quebrar uma das APIs. Às vezes, a quantidade de trabalho é tão grande que os mantenedores/desenvolvedores simplesmente desistem, deixando novos recursos ou potencial melhoria de desempenho para o novo hardware não implementado.
Durante o último ciclo de lançamento, Boris Brezillon tentou solucionar esse problema convertendo alguns desses drivers antigos na API mais recente chamada exec_op. Dado o número de drivers que ainda usam as APIs antigas, ainda temos um longo caminho a percorrer antes que as coisas sejam unificadas, mas qualquer progresso, mesmo pequeno, é melhor do que o status quo em que estávamos.
Corrigido o MediaTek sem nenhum bug
O MediaTek possui uma família de SoCs usados em vários Chromebooks, como o MT8173 usado no Chromebook Lenovo N23 e Acer Chromebook R13, além do MT8183 no Chromebook Lenovo IdeaPad Duet.
Estamos trabalhando duro para ter um melhor suporte de upstream para esses dispositivos, especialmente Enric Balletbo, que está envolvido no suporte de upstream do kernel e do Chromebook há muito tempo. As exibições nos dispositivos baseados no MT8173 não funcionavam ao usar o kernel da linha principal; isso foi corrigido com esta versão do kernel.
A causa desse defeito foi um conflito entre o relógio e os drivers DRM.
Suporte para decodificação de JPEGs com tabelas Huffman otimizadas no driver Coda (plataformas i.MX 6)
É possível obter uma melhor compactação com imagens JPEG quando as tabelas Huffman que elas contêm são otimizadas especificamente para seu conteúdo individual; no entanto, o driver Coda suporta apenas decodificação de JPEGs que usem tabelas padrão/não otimizadas. Adrian Ratiu, com a ajuda de Andrzej Pietrasiewicz, adicionou suporte ao driver Coda para decodificar uma ampla variedade de imagens JPEG com tabelas Huffman otimizadas. O decodificador de vídeo Chips & Media CODA960 é usado principalmente nos SoCs da série NXP i.MX 6.
Correção de deadlock no subsistema SCSI
Para melhorar o driver iSCSI, Gabriel Krisman Bertazi criou uma correção para um problema de impasse que afetava os drivers iSCSI em condições de pouca memória. Esse bug, que poderia ser acionado por uma recuperação de memória, impediu o daemon iSCSI de recuperar o dispositivo e concluir a recuperação. Isso poderia, com efeito, travar o sistema. A solução de Gabriel impede que o problema aconteça, enquanto protege o driver iSCSI contra vários outros problemas possíveis que surgem de todos os comandos iSCSI que compartilham o mesmo bloqueio de execução.
Melhorar o suporte do sistema de bateria inteligente (SBS) no subsistema de fonte de alimentação
O Smart Battery System (SBS) é uma especificação para gerenciar uma ‘bateria inteligente‘. Essas baterias podem ser encontradas no quadro da Novena e em vários dispositivos Chroombook, como os Chromebooks Scarlet, o veyron-jerry e outros. Sebastian Reichel enviou um patch para melhorar o driver da bateria do SBS. Muito mais informações (por exemplo, data do fabricante, corrente/tensão máx. de carga solicitadas pela bateria, …) do controlador de bateria inteligente agora estão expostas ao espaço do usuário por meio de variáveis sysfs e uevents 1. É interessante mencionar que o número de variáveis uevents ultrapassou o máximo de 32 definidas e, portanto, teve que ser atualizado para 64. Dois patches da série, adicionando suporte ao PEC (Packet Error and Correction), não foram incluídos no lançamento e são esperados para a versão 5.9.
Melhoria da documentação printk
Os desenvolvedores do kernel usam a função printk como sua principal ferramenta de log. É uma parte tão fundamental do kernel que mereceu algumas melhorias na documentação. Ricardo Cañuelo aprimorou a documentação printke macros pr_*com esse patch.
Suporte do Debian no i.MX 6
O suporte a distribuições Linux como o Debian e seus derivados é uma das muitas maneiras pelas quais a Collabora cumpre sua missão e ajuda os usuários finais de código aberto. O kernel armhf do Debian precisa suportar uma variedade de placas diferentes, para que ele não use os padrões padrão do Linux.
Com o defconfig personalizado do Debian para armhf, o cpufreq falhou ao analisar as placas i.MX 6. Um conjunto de patches foi desenvolvido para a linha principal do Linux e o Linux Debian, o primeiro deles, de autoria de Walter Lozano, já está incluído nesta versão.
Contribuições contínuas com correções, limpezas, documentação, revisões e testes
Enquanto trabalhamos com vários projetos de código-fonte aberto, muitas vezes nossos engenheiros se deparam com pequenos problemas ou coisas que valem a pena melhorar, como documentação ou limpeza.
Tentamos contribuir com a montante de forma contínua. Para a versão 5.8, tivemos várias contribuições para áreas, incluindo correções no núcleo V4L2, mapeamento de dispositivos, I3C, energia, relógios, MTD, ASoC e muito mais.
Gostamos e nos orgulhamos de ser uma parte ativa da comunidade, ajudando e melhorando os projetos que usamos. Isso também inclui fornecer ajuda para revisar e testar patches de outros membros da comunidade.
O post Kernel 5.8 traz atualizações importantes para os SoCs RockChip e MediaTek apareceu primeiro em SempreUPdate.
