Relatório de progresso do Asahi Linux 7.0

 (asahilinux.org)
1 pontos por GN⁺ 3 일 전 | 1 comentários | Compartilhar no WhatsApp
  • O suporte a Linux para Apple Silicon avançou em várias frentes ao mesmo tempo, incluindo automação do instalador, gerenciamento de energia, áudio, display e ativação do M3
  • O Asahi Installer foi reformulado para separar o manifesto de imagens da base de código e adotar implantação via GitHub workflow, permitindo atualizações mais frequentes; na versão 0.8.0, adicionou atualização do m1n1 stage 1, suporte à instalação no Mac Pro e um modo de atualização de firmware
  • O firmware de calibração do ALS agora pode ser extraído do macOS e atualizado novamente mesmo após a instalação; as interrupções no áudio Bluetooth desapareceram com o suporte aos comandos de coexistência da Broadcom; e o suporte ao PMP reduz o consumo ocioso em cerca de 0,5 W no M1 Pro
  • O suporte a VRR ainda não pode ser exposto corretamente ao userspace por causa das limitações do Apple DCP, mas, quando o pull request for mesclado, será possível forçar a ativação por parâmetro de módulo do kernel; no trabalho de upstream da pilha de áudio, também entraram uma API genérica para bus keeper e suporte a taxas de amostragem adicionais no CS42L84
  • O escopo de suporte ao M3 foi ampliado para PCIe, dispositivos de entrada, RTC, reboot controller e NVMe, e o Fedora Asahi Remix 44 mantém o cronograma de lançamento alinhado ao Fedora 44 com um novo fluxo de instalação baseado em Plasma

Automação do instalador e atualização de firmware

  • O Asahi Installer, que recebeu poucas atualizações por quase 2 anos, tinha um ciclo de atualização longo devido ao processo manual de release e à dependência de permissões administrativas no CDN, e as mudanças acumuladas desde a tag de junho de 2024 também cresceram bastante
  • Na instalação somente com UEFI, apenas m1n1 stage 1, Devicetree e U-Boot são instalados, então, se o Devicetree incluído no pacote do instalador não corresponder ao esperado pelo kernel, o boot pode falhar completamente
    • Durante o trabalho de upstream, as bindings de Devicetree mudaram, acumulando incompatibilidades, e no kernel 6.18 houve muitas mudanças relacionadas ao USB da Apple, tornando impossível inicializar mídia live com 6.18 ou superior
  • O manifesto de imagens instaláveis foi separado em asahi-installer-data, permitindo atualizações independentes da base de código do instalador
  • A distribuição de asahi-installer agora é automatizada via GitHub workflow
    • Pushes para a branch main são compilados e enviados automaticamente para https://alx.sh/dev
    • Pushes de tags no GitHub são implantados automaticamente em https://alx.sh
  • A versão mais recente, 0.8.0, atualizou o m1n1 stage 1 incluído para 1.5.2 e adicionou suporte à instalação no Mac Pro e um modo de atualização de firmware

ALS e extração de firmware

  • No ambiente True Tone da Apple, é necessário medir não apenas o brilho ambiente, mas também as características de cor da iluminação, então a precisão no processamento e na calibração dos dados do ALS se torna importante
  • O próprio AOP e o driver de ALS já funcionavam, mas, sem os dados de calibração, a precisão dos dados brutos de ALS fornecidos pelo AOP ficava baixa
    • Esses dados de calibração são um blob binário que precisa ser carregado no AOP em tempo de execução e, como não pode ser redistribuído, precisa ser obtido do macOS durante a instalação
  • O Asahi Installer reúne os firmwares necessários para o Linux e os armazena na EFI System Partition, e um módulo do Dracut os monta em subdiretórios de /lib/firmware/ para que os drivers possam encontrá-los
  • Para evitar o problema de precisar de firmware adicional depois que o sistema já está instalado, o instalador passou a suportar atualização automática do pacote de firmware do fornecedor
    • A partir do ALS, é possível inicializar no macOS ou no macOS Recovery, executar o instalador novamente e seguir o prompt para atualizar o firmware necessário
  • Para suporte a ALS e upgrades posteriores de firmware, são necessários o kernel Asahi 6.19 ou superior e iio-sensor-proxy

Gerenciamento de energia e PMP

  • O consumo de energia em idle continuou sendo um problema, especialmente nos SoCs Pro/Max/Ultra, e o gerenciamento de energia nessa plataforma tem uma estrutura complexa envolvendo PMGR e PMP
  • O PMGR é responsável por ligar e desligar os domínios de energia do SoC, enquanto o PMP processa relatórios de estado de energia enviados por blocos do SoC e pelos núcleos de aplicação por meio de memória compartilhada
    • Se o PMP não inicializar, ele não consegue ler esses relatórios, e certos recursos de gerenciamento de energia também deixam de funcionar
  • O driver de suporte a PMP criado por chaos_princess fez com que o PMP passasse a receber relatórios dos blocos do SoC e do PMGR, alcançando uma redução de cerca de 0,5 W em idle em um MacBook Pro M1 Pro de 14 polegadas
    • Isso equivale a aproximadamente 20% menos consumo em idle
  • Ainda é necessário trabalho adicional para alcançar tempos de idle e suspensão no nível do macOS, mas esta mudança representa um grande avanço
  • O M1 básico usa uma variante antiga de PMP incompatível com as gerações posteriores, e dd-dreams está trabalhando nesse suporte
  • O PMP ainda não foi validado em todos os dispositivos suportados e não há plano de ativá-lo por padrão antes da mesclagem em upstream
    • Usuários que podem modificar o Devicetree podem ativá-lo definindo APPLE_USE_PMP no DTS do dispositivo

Correção das interrupções no áudio Bluetooth

  • Bluetooth e Wi‑Fi compartilham a mesma faixa de 2,4 GHz, o que facilita interferências, e conexões em que latência e continuidade são críticas, como streams de áudio, precisam de prioridade mais alta
  • A configuração de coexistência da Broadcom é tratada por comandos de extensão vendor-specific do Bluetooth HCI, mas o kernel Linux upstream não os suportava, causando perda de pacotes de áudio durante varreduras de Bluetooth
    • Se o KDE Connect disparasse uma varredura de Bluetooth, isso podia causar cortes no áudio
  • chaos_princess adicionou suporte a esses comandos à pilha Bluetooth do kernel, e o BlueZ marca todos os streams de áudio como high priority, então os comandos necessários são acionados automaticamente durante a transmissão
  • Como resultado, as falhas e cortes no áudio Bluetooth deixaram de ocorrer

DCP e VRR

  • A interface de firmware do DCP é muito grande e instável entre versões, e, como outros trabalhos de hardware tiveram prioridade após o suporte básico a display, recursos como VRR ficaram pendentes
  • O suporte a VRR exige troca de pacotes especiais entre o controlador de display e a tela, ajuste do vertical blanking conforme o momento de exibição do frame, anúncio da capability de VRR da tela e integração com KMS
  • Durante a investigação, descobriu-se que um parâmetro do DCP, que era definido como 0 ao energizar um monitor externo, alternava entre 0x300000 e 0x0 ao ligar e desligar o VRR
    • A tela de teste tinha taxa mínima de atualização de 48 Hz, e no formato de ponto fixo do DCP, 48 era 0x300000
    • Esse parâmetro não era para a sequência de energia, mas sim um toggle da taxa mínima de atualização do VRR; definir 0 antes do modeset acabava desativando o VRR
  • A tela interna ProMotion do MacBook Pro também é ativada da mesma forma, mas o painel interno não anuncia EDID/DisplayID, então o driver Linux identifica que se trata de um LCD interno e define estaticamente as propriedades necessárias
  • O VESA DisplayPort Adaptive Sync e a API de KMS não permitem exigir modeset na troca de estado do VRR, mas o Apple DCP não consegue evitar isso
    • Por essa limitação, não é possível expor o VRR corretamente ao userspace, e o KWin também ignora esse tipo de interface
  • No momento, quando este pull request for mesclado, será possível ativar VRR forçado com o parâmetro de módulo do kernel appledrm.force_vrr
    • Se a tela suportar VRR, o DCP usará VRR sem informar isso ao KMS nem ao compositor
    • Funcionou bem no KWin, mas a experiência pode variar em outros compositores
  • No caso do HDMI, não há proibição de modeset entre trocas de VRR, e outros controladores de display, como os da Intel, funcionam de forma semelhante
    • Em upstream, seguem as discussões entre manter o modo VRR sempre ativado ou permitir modeset durante a troca; quando a direção for definida, a ideia é expor o VRR da forma esperada

Upstream da pilha de áudio e expansão de taxas de amostragem

  • O trabalho de upstream de toda a pilha de áudio continua, e drivers de conector de fone e amplificador de alto-falante relacionados à Cirrus Logic e Texas Instruments, periféricos I2S e mudanças no controlador DMA da Apple já foram mesclados
  • A proteção de alto-falantes nessa plataforma funciona com o amplificador TI enviando tensão e corrente via I2S ao SoC, que calcula a temperatura da bobina de voz junto com os parâmetros de Thiele/Small do alto-falante
  • Em uma estrutura em que os pinos de data transmit de vários amplificadores são ligados em série e os canais esquerdo e direito são combinados por OR, quando um lado transmite, o outro precisa garantir logic low, então é necessária uma configuração de bus keeper
  • Antes, o bus keeper era tratado por drivers específicos dos chips amplificadores e por bindings dedicadas de Devicetree, mas isso era limitado demais para upstream e foi substituído por uma API genérica
    • Agora, qualquer componente ASoC pode expor a existência de um bus keeper configurável, e o driver da plataforma pode aplicar em tempo de execução as configurações necessárias
    • Esse patchset foi mesclado no Linux 7.1
  • O suporte a variantes de chip específicas da Apple também continua se ampliando
    • Nos amplificadores de alto-falante da TI, foi possível adicionar suporte às variantes da Apple aos drivers upstream do TAS2764 e TAS2770 com relativa facilidade
    • O CS42L84 difere bastante do CS42L42, por isso precisou de um driver Linux separado, que já foi incorporado ao upstream
  • Se a análise se baseasse apenas no rastreamento do macOS, haveria a limitação de expor apenas os recursos usados pelo macOS, e o CS42L84 inicialmente também passou a suportar apenas 48 kHz e 96 kHz
    • Essa limitação fazia o PipeWire reamostrar outros streams, consumindo mais CPU e bateria e reduzindo a qualidade de áudio
  • Ao aplicar ao driver do CS42L84 outros valores comuns de taxa de amostragem encontrados no datasheet do CS42L42, o suporte por hardware a 44.1, 88.2, 176.4 e 192 kHz passou a funcionar tanto na entrada quanto na saída do conector de fone
    • Esse patch foi enviado ao upstream, mesclado no Linux 7.1 e também backportado para o kernel Asahi 6.19.9

Expansão do suporte ao M3

  • A árvore de kernel do Asahi também está recebendo patches adicionais de ativação de hardware para dispositivos M3
  • O escopo inclui PCIe, teclado e trackpad do MacBook, RTC baseado em SMC, reboot controller e controlador NVMe
  • Com o trabalho de Michael Reeves e Alyssa Milburn, o nível de suporte ao Linux no M3 chegou a um estágio aproximadamente semelhante ao primeiro alpha do Asahi Linux para M1
  • A preparação para liberar imediatamente a instalação do M3 no Asahi Installer ainda não terminou, mas continua avançando

Fedora Asahi Remix 44

  • Apesar do atraso do Fedora Asahi Remix 43, o Fedora Asahi Remix 44 mantém o plano de lançamento no mesmo dia do Fedora Linux 44, em 28 de abril, ou dentro de alguns dias dessa data
  • A nova instalação baseada em KDE Plasma passará a aproveitar os novos recursos do Plasma 6.6
    • O Plasma Setup substitui o antigo assistente de configuração baseado no Calamares, oferecendo um fluxo nativo do Plasma para criação de conta e configuração do sistema
    • O Plasma Login Manager se torna o greeter e session manager padrão, substituindo o SDDM
  • Essa mudança se aplica apenas a novas instalações; as configurações de usuários que atualizaram a partir de versões anteriores do Fedora Asahi Remix não serão alteradas
  • O Fedora Asahi Remix 44 descontinua os pacotes vendorizados de Mesa e virglrenderer
    • Usuários que ainda não fizeram a migração manual serão movidos automaticamente para os pacotes Mesa e virglrenderer dos repositórios upstream do Fedora

Apoio e suporte de infraestrutura

Leituras relacionadas

1 comentários

 
GN⁺ 3 일 전
Comentários no Hacker News

  • O CS42L84 estava configurado no macOS para usar apenas 48/96 kHz, mas ao pegar outros valores de sample rate da folha de dados do CS42L42 e colocá-los no driver, aparentemente funcionou normalmente
    Um patch adicionando suporte a 44,1/88,2/176,4/192 kHz na entrada e saída do conector de fone foi aceito no upstream, mesclado no 7.1 e também backportado para o kernel Asahi 6.19.9, então já dá para usar agora mesmo
    O rastreamento dos chips e a engenharia reversa são realmente impressionantes

    • A parte mais surpreendente é que, ao suportar só 48/96 kHz, o PipeWire acaba consumindo mais CPU e bateria por causa do resampling
      A Apple é obcecada por eficiência energética, então fico me perguntando por que ainda deixa isso assim
    • O fato de agora ser possível fazer reprodução de CD/FLAC em 44,1 kHz bit-perfect parece um recurso realmente grande

  • Os textos técnicos e os resultados da equipe do Asahi são realmente incríveis, mas ainda preocupa um pouco que isso continue sendo um projeto separado, em vez de algo sustentado dentro do kernel mainline ou de distribuições principais como Ubuntu, Debian e Fedora
    Projetos de engenharia reversa até conseguem produzir resultados úteis com relativa facilidade até uns 80%, mas para chegar aos 95% de acabamento que bastam para usuários comuns, normalmente é preciso quase o mesmo volume de trabalho árduo e minucioso

    • O Asahi também está fazendo bastante upstreaming justamente nessa direção
      Um dos grandes motivos para o progresso recente ter desacelerado foi o foco em reduzir a quantidade de diffs, e bastante coisa já entrou no kernel mainline
      O Asahi também serve como espaço para experimentar recursos novos
    • Há ainda a dificuldade extra de que o próprio ARM Mac é um alvo em movimento constante
      A Apple não tem nenhuma intenção de oferecer estabilidade ou suporte para o Asahi Linux e, diferentemente da indústria de PCs, não tem motivo para manter compatibilidade de longo prazo, então provavelmente continuará sem se importar em fazer mudanças que compliquem a vida do Asahi
    • A parte boa do Linux é que ele é software livre, então não fica preso a acionistas nem à rentabilidade
      Uso o Asahi como sistema principal em um MacBook Air M1 e estou bem satisfeito; mesmo com limitações como a bateria cair 1% por hora em suspensão, o estado atual ainda é muito melhor do que simplesmente não existir por não estar 100% completo
      Também não sinto tanta necessidade de que ele esteja perfeitamente lapidado para o grande público
    • O desenvolvimento do kernel mainline sempre funciona assim: cada um trabalha no seu próprio fork e depois envia patches para o upstream
      O Asahi parece especial porque há muito hardware estranho e dedicado, exigindo vários drivers específicos, mas ninguém desenvolve diretamente na árvore do Linus
    • A apresentação da 39c3 em https://youtu.be/3OAiOfCcYFM também foi boa
      No fim das contas, o objetivo é fazer com que o Linux tenha suporte nativo ao Apple Silicon

  • Espero que esse projeto continue ganhando força
    A combinação hardware da Apple + Linux parece o sistema menos quebrado rodando no melhor hardware, enquanto o macOS fica cada vez mais confuso com bugs e mudanças que viram tudo de cabeça para baixo a cada versão

    • Talvez você mude de ideia se usar um Framework com Fedora
      A experiência foi muito fluida, e há expectativa de que o próximo Framework 13 Pro tenha bateria e trackpad no nível do macOS — ou até bateria melhor
    • Já usei os três principais sistemas operacionais, e o macOS foi o que teve menos bugs e simplesmente funcionou melhor
      No Linux eu sempre acabava fazendo patches estranhos por causa de compatibilidade de áudio ou vídeo, e no Windows os problemas de bateria eram sérios
      Também parece que muita gente que gosta de ajustar o Linux, no fundo, quer uma experiência tipo Mac, só que com mais possibilidade de customização
    • No geral isso é verdade, mas o ecossistema em torno do MLX está bem coeso
      O I/O de disco não é grande coisa e o sistema operacional tem bugs, mas pelo menos ML compila e roda no sistema mais recente
      Já com o rocm, parece que está quase lá, mas aí você depende de pacotes pré-compilados ou de um Ubuntu com mais de 2 anos, o que é frustrante
      https://github.com/ROCm/TheRock/issues/3477
    • Usei recentemente um MacBook Air para trabalho e acho difícil concordar com a ideia de que o hardware é de altíssimo nível
      Parece que com apenas 5 euros já daria para achar um teclado melhor

  • Não entendo muito bem por que a Apple não coopera com esse esforço nem divulga documentação
    Motivos tradicionais como vantagem competitiva ou segredo já não parecem tão convincentes

    • O verdadeiro motivo pode ser mais simples
      A Apple tem margens altas no hardware, então vender MacBooks para usuários de Linux já dá lucro, mas no momento em que reconhecer oficialmente o suporte a Linux, isso vira responsabilidade de suporte
      Cada kernel panic geraria uma visita ao Genius Bar, e cada bug de driver chamaria o @AppleSupport; então, do ponto de vista da Apple, manter tudo como não oficial pode ser o melhor cenário: vende o hardware e evita o custo de suporte
    • Quase não há ganho financeiro, e ainda surgiria o ônus de documentar o Linux cada vez que o hardware mudar
      Também não deve parecer atraente para a Apple por se tratar de uma base de usuários pequena e, ao mesmo tempo, das mais barulhentas e críticas
    • Pode ser muito mais fácil simplesmente traçar a linha e dizer “não jogamos esse jogo” do que ser criticada por uma abertura seletiva ou por quebrar compatibilidade com interfaces não públicas
      Internamente, isso também evita discussões constantes sobre algo fora das prioridades da empresa
    • Isso parece tocar quase diretamente na questão do right to repair
      Um notebook é composto de vários componentes de hardware e dos drivers que os fazem funcionar, então isso levanta a pergunta: o que eu comprei foi um pacote inseparável de hardware e drivers, ou eu deveria receber manuais para poder salvar uma das partes por conta própria quando a outra falhar?
      A Apple pode argumentar que drivers não se desgastam como engrenagens ou motores, mas isso não significa que o direito de entender como algo funciona desapareça
      Não seria tão surpreendente se algum dia surgisse um caso-teste em tribunal em que /System/Trackpad.kext fosse atingido por uma nave espacial e alguém exigisse a documentação para escrever o próprio driver
    • Parece correto
      Seria fácil para a Apple dar suporte a isso, e ela provavelmente ganharia bastante boa vontade da comunidade

  • Fico pensando se haveria interesse em uma edição do Asahi Remix focada na experiência padrão de um Mac
    Algo com cmd como tecla modificadora principal, atalhos e tema no estilo Mac, além de gestos configurados por padrão
    Dá para ajustar qualquer distribuição para isso, mas padrões bem curados ainda têm seu valor

    • Tornar o cmd a “tecla modificadora principal” é algo meio complicado
      Em um ambiente X/Wayland típico, o Cmd já é central nas funções do DE, enquanto no nível dos aplicativos o Ctrl é o principal, então mudar isso acaba criando bastante sobreposição
    • Consegui deixar o KDE bem parecido
      Pedi ao Claude Code para implementar isso, e ele pesquisou na web e até gerou os arquivos de configuração
    • Um keymap centrado em Cmd parece praticamente uma batalha perdida
      Tentei várias vezes, mas no fim aceitei viver com Ctrl e vendi meu último MacBook

  • Fico curioso para saber se a máquina de desenvolvimento dos sonhos, MacBook Pro + Linux, vai se tornar realidade primeiro pelo lado do hardware ou do software
    Resta ver se o Asahi chega lá primeiro pelo lado do software, ou se o Framework chega primeiro pelo lado do hardware

  • Se surgir uma combinação MacBook Neo + Asahi, ela parece que seria realmente poderosa

  • É bom ver que o suporte ao M3 está avançando de forma consistente enquanto o backlog do upstream é resolvido e as ferramentas melhoram
    Patches de suporte a PCIe, teclado e trackpad de MacBook, RTC baseado em SMC, reboot controller e controlador NVMe estão entrando na árvore do kernel Asahi, e com isso o nível de suporte Linux ao M3 chega mais ou menos ao mesmo estágio do primeiro alpha do Asahi Linux para M1

    • Nesse ritmo, talvez só fique realmente utilizável perto do lançamento do M6

  • O fato de esses relatórios do projeto continuarem mostrando avanços importantes e apontando com precisão onde os usuários reais sentem incômodo faz a equipe do Asahi parecer muito experiente
    Dá vontade de voltar completamente para o Asahi em breve

  • A notícia de que o M3 está perto do alpha é excelente, e agora fico até na expectativa do M4
    Já o que a Apple pode aprontar com o macOS neste ano ou no próximo é algo pelo qual não tenho expectativa nenhuma