Linux: Visibilidade dos planos de desenvolvimento de OS específicos do RPi para a comunidade?

Olhando para os últimos anos, o que você identificaria como empreendimentos em que a comunidade teria se beneficiado de um aviso prévio?

Tão certo quanto a noite segue o dia, os números das versões do Linux aumentam. Tentamos obter versões funcionais de cada candidato a lançamento o mais rápido possível, mesmo que nem todos cheguem ao código de produção. Ao mesmo tempo, embora em um ritmo muito mais lento, o Debian está produzindo seus principais lançamentos e provavelmente iremos para o Buster em algum momento no futuro.

O próprio desenvolvimento de software do Raspberry Pi geralmente está vinculado a lançamentos de hardware e, se você espera um aviso prévio sobre eles, ficará desapontado.

Como diz Phil, muitas coisas estão ligadas a lançamentos de hardware.

Quase todas as coisas que Eric está relatando são coisas que estão em andamento há algum tempo, mas enquanto ele estava aqui, tivemos a chance de discutir e identificar as partes que faltam para aproximar o KMS (falso) da linha principal.
Ele tem experiência muito limitada com codecs e câmeras, mas muito em 3D e KMS. Tenho um conhecimento muito limitado de V3D, um pouco mais sobre composição geral e muitos codecs e câmeras. Combine os dois e passe um pouco do conhecimento, e obteremos algum progresso :-)

Pessoalmente, gostaria de ver changelogs mais detalhados (por exemplo, eles sempre dizem "novo kernel, novo firmware", mas sem qualquer explicação sobre o que mudou ou foi corrigido).

Para o kernel e firmware, por exemplo, é muito aberto aqui no Github, para os Releases Raspbian eu não vejo nada disso, Releases Raspbian apenas parecem "surgir do nada";)

@pelwell logo no topo da minha cabeça, o VC SONAME renomeando. Era para ser anunciado com antecedência, mas pelo que eu sei isso nunca aconteceu, e a primeira vez que soube disso foi depois que todas as minhas construções quebraram. E sim eu percebo que não tem nada a ver com o kernel. :)

Veja: https://github.com/raspberrypi/firmware/issues/625#issuecomment -230356111

@pelwell @ 6by9 , nos beneficiaríamos de notificações avançadas sobre especiais de RPI como VC, firmware, desktop.
O novo HW está explicitamente fora do escopo.

Um exemplo é o driver VC4 em que a postagem do blog de Eric indicou algumas 'pontas soltas' descritas como 'Alguém precisa'.
Amarrar todas as atividades necessárias juntas por meio de um marco pode atrair contribuintes para selecioná-las e, como resultado, permitir a fusão da melhoria VC4 planejada '

Amarrar todas as atividades necessárias juntas por meio de um marco pode atrair contribuintes para selecioná-las e, como resultado, permitir a fusão da melhoria VC4 planejada 'não precisa mais de gpu_mem = mais' um pouco mais cedo.

Visto que isso está exigindo trabalhos significativos dentro do firmware e acompanhamento de trabalho em uma nova versão do vc-sm (espero que com uma pequena possibilidade de upstreaming), não é algo que pode ser compartilhado.

Em seguida, há grandes discussões necessárias sobre como gerenciamos a migração de gpu_mem para cma. A nova alocação remota via vc-sm vai tornar o firmware legado da pilha GLES impraticável, pois a latência de ida e volta para alocar memória vai matar o desempenho (decodificação de vídeo / câmera faz todas as alocações antecipadamente, então é uma configuração relativamente pequena aumento de tempo). Alternar entre CMA e gpu_mem exigirá, portanto, um pouco de mágica no firmware olhando para os nós da árvore de dispositivos na esperança de descobrir em qual modo o usuário está executando, ainda mais complicado pelo fato de que as coisas da árvore de dispositivos atuais são todas feitas após gpu_mem já está alocado.
Nada disso pode ser compartilhado como está no firmware, então, novamente, não se beneficia de ser definido como um marco.

Pode haver algum benefício em definir mais alguns detalhes do shim DispmanX proposto para KMS e, possivelmente, o conector de write-back para transpor. O primeiro deles depende principalmente do RPT, como conhecemos o DispmanX, mas o principal obstáculo é ter uma solução diferente entre o X11 e um sistema baseado em console. O último Eric tem algumas idéias, então caberia a ele concretizá-las.

Obrigado @ 6by9.
Estou ansioso para ver mais sobre o plano de 'como gerenciar a migração de gpu_mem para cma' em algum momento no futuro.

Este não é realmente um problema do kernel, então fechando. No entanto, fique à vontade para adicionar comentários ao final da edição.