▲

Asahi Linux 진행 보고서 Linux 7.0

 (asahilinux.org)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • Apple Silicon용 Linux 지원은 설치기 자동화, 전력 관리, 오디오, 디스플레이, M3 활성화까지 여러 축에서 동시에 진전됨
  • Asahi Installer는 이미지 매니페스트를 코드베이스와 분리하고 GitHub workflow 배포를 도입해 더 자주 갱신할 수 있게 바뀌었으며, 0.8.0에서 m1n1 stage 1 갱신과 Mac Pro 설치 지원, 펌웨어 업데이트 모드를 추가함
  • ALS 보정 펌웨어는 macOS에서 추출해 설치 뒤에도 다시 갱신할 수 있게 됐고, Bluetooth 오디오 끊김은 Broadcom coexistence 명령 지원으로 사라졌으며, PMP 지원은 M1 Pro에서 유휴 전력을 약 0.5W 줄임
  • VRR 지원은 Apple DCP 제약 때문에 아직 userspace에 정상 노출되지는 않지만, pull request가 병합되면 커널 모듈 파라미터로 강제 활성화할 수 있게 되며, 오디오 스택 upstream 작업으로 bus keeper 범용 API와 CS42L84의 추가 샘플레이트 지원도 들어감
  • M3 지원 범위는 PCIe, 입력 장치, RTC, reboot controller, NVMe까지 넓어졌고, Fedora Asahi Remix 44는 새 Plasma 기반 설치 흐름과 함께 Fedora 44 시점에 맞춰 출시를 유지함

설치기 자동화와 펌웨어 갱신

  • 거의 2년 동안 갱신이 드물었던 Asahi Installer는 수동 릴리스 절차와 CDN 관리자 권한 의존성 때문에 업데이트 주기가 길어졌고, 2024년 6월 태그 이후 변화 누적도 커짐
  • UEFI 전용 설치에서는 m1n1 stage 1, Devicetree, U-Boot만 설치하므로, 설치기 번들 안의 Devicetree가 커널 기대값과 어긋나면 부팅 자체가 막히게 됨
    • upstream 진행 중 Devicetree 바인딩이 바뀌면서 불일치가 누적됐고, kernel 6.18에서는 Apple USB 관련 변경이 많아져 라이브 미디어로 6.18 이상 부팅할 수 없게 됨
  • 설치 가능한 이미지 매니페스트를 asahi-installer-data로 분리해 설치기 코드베이스와 독립적으로 갱신할 수 있게 바뀜
  • asahi-installer 배포는 이제 GitHub workflow로 자동화됨
  • 최신 0.8.0은 번들된 m1n1 stage 1을 1.5.2로 올렸고, Mac Pro 설치 지원과 펌웨어 업데이트 모드를 추가함

ALS와 펌웨어 추출

  • Apple의 True Tone 환경에서는 주변 밝기뿐 아니라 조명 색 특성까지 측정해야 하므로, ALS 데이터 처리와 보정 정확도가 중요해짐
  • AOP와 ALS 드라이버 자체는 이미 동작했지만, 보정 데이터 없이는 AOP가 내놓는 ALS 원시 데이터 정확도가 낮아짐
    • 이 보정 데이터는 런타임에 AOP로 올려야 하는 바이너리 blob이며, 재배포할 수 없어 설치 시 macOS에서 가져와야 함
  • Asahi Installer는 Linux에 필요한 펌웨어를 모아 EFI System Partition에 저장하고, Dracut 모듈이 이를 /lib/firmware/ 아래 하위 디렉터리로 마운트해 드라이버가 찾게 만듦
  • 이미 설치된 뒤 추가 펌웨어가 필요해지는 문제를 막기 위해, 설치기가 vendor firmware package 자동 갱신을 지원하게 바뀜
    • ALS부터는 macOS 또는 macOS Recovery로 부팅한 뒤 설치기를 다시 실행해 프롬프트를 따라가면 필요한 펌웨어를 갱신할 수 있음
  • ALS 지원과 이후 펌웨어 업그레이드를 위해서는 Asahi kernel 6.19 이상과 iio-sensor-proxy가 필요함

전력 관리와 PMP

  • 유휴 전력 소모는 특히 Pro/Max/Ultra SoC에서 계속된 문제였고, 이 플랫폼의 전력 관리는 PMGR과 PMP가 함께 얽힌 복잡한 구조를 가짐
  • PMGR은 SoC 전력 도메인을 켜고 끄는 역할을 맡고, PMP는 SoC 블록과 애플리케이션 코어가 공유 메모리로 전달하는 전력 상태 보고를 받아 처리함
    • PMP가 부팅되지 않으면 이 보고를 읽지 못하고, 특정 전력 관리 기능도 동작하지 않게 됨
  • chaos_princess가 만든 PMP 지원 드라이버는 SoC 블록과 PMGR 보고를 PMP가 받도록 만들었고, 14형 M1 Pro MacBook Pro 유휴 상태에서 약 0.5W 절감을 달성함
    • 이는 유휴 전력 약 20% 감소에 해당함
  • macOS 수준의 유휴·절전 시간까지는 아직 추가 작업이 필요하지만, 이번 변경은 큰 전진에 가까움
  • 기본 M1은 이후 세대와 호환되지 않는 구형 PMP 변형을 쓰며, dd-dreams가 해당 지원을 진행 중임
  • PMP는 아직 모든 지원 기기에서 검증되지 않았고 upstream 병합 전까지 기본 활성화할 계획도 없음
    • Devicetree를 수정할 수 있는 사용자는 기기 DTS에 APPLE_USE_PMP를 정의해 켤 수 있음

Bluetooth 오디오 끊김 수정

  • Bluetooth와 WiFi는 같은 2.4GHz 대역을 공유해 간섭이 생기기 쉬우며, 오디오 스트림처럼 지연과 연속성이 중요한 연결은 더 높은 우선순위가 필요함
  • Broadcom의 coexistence 설정은 Bluetooth HCI의 vendor-specific 확장 명령으로 처리되는데, upstream Linux 커널은 이를 지원하지 않아 Bluetooth 스캔 시 오디오 패킷 손실이 생김
    • KDE Connect가 Bluetooth 스캔을 유발하면 오디오 드롭이 발생할 수 있었음
  • chaos_princess가 이 명령 지원을 커널 Bluetooth 스택에 추가했고, BlueZ는 모든 오디오 스트림을 high priority로 표시하므로 스트리밍 중 필요한 명령이 자동으로 트리거됨
  • 그 결과 Bluetooth 오디오 드롭아웃은 더 이상 발생하지 않게 됨

DCP와 VRR

  • DCP 펌웨어 인터페이스는 매우 크고 버전마다 불안정하며, 그동안 기본 디스플레이 지원 이후 다른 하드웨어 작업이 우선되면서 VRR 같은 기능은 남아 있었음
  • VRR 지원에는 디스플레이 컨트롤러와 디스플레이 간 특수 패킷 교환, 프레임 표시 타이밍에 따른 vertical blanking 조절, 디스플레이의 VRR capability 광고, 그리고 KMS 연동이 모두 필요함
  • 추적 과정에서 외부 디스플레이 전원 인가 때 0으로 설정하던 DCP 파라미터가 VRR on/off 시 0x300000과 0x0 사이에서 바뀌는 점이 드러남
    • 테스트 디스플레이 최소 주사율이 48Hz였고, DCP 고정소수점 형식에서 48은 0x300000이었음
    • 이 파라미터는 전원 시퀀스용이 아니라 VRR 최소 주사율 토글이었고, modeset 전 0을 넣으면 VRR 비활성화로 이어짐
  • MacBook Pro의 ProMotion 내장 디스플레이도 같은 방식으로 활성화되지만, 내부 패널은 EDID/DisplayID를 광고하지 않아 Linux 드라이버가 내부 LCD 여부를 판단해 필요한 속성을 정적으로 설정하게 됨
  • VESA DisplayPort Adaptive Sync와 KMS API는 VRR 상태 전환에 modeset 요구를 허용하지 않는데, Apple DCP는 이를 피하지 못함
    • 이 제약 때문에 VRR을 userspace에 정상 노출할 수 없고, KWin도 그런 인터페이스를 무시하게 됨
  • 현재는 pull request가 병합되면 appledrm.force_vrr 커널 모듈 파라미터로 강제 VRR을 켤 수 있게 됨
    • 디스플레이가 VRR을 지원하면 DCP가 KMS나 compositor에 알리지 않고 VRR을 사용함
    • KWin에서는 잘 동작했지만 다른 compositor에서는 경험이 다를 수 있음
  • HDMI 쪽은 VRR 전환 간 modeset을 금지하지 않으며, Intel 같은 다른 디스플레이 컨트롤러도 비슷하게 동작함
    • upstream에서는 VRR 모드를 항상 켜 두는 방식 또는 전환 중 modeset 허용 방식을 두고 논의가 진행 중이며, 방향이 정해지면 기대한 방식으로 VRR을 노출할 계획임

오디오 스택 upstream과 샘플레이트 확장

  • 오디오 스택 전체의 upstream 작업이 계속 진행 중이며, Cirrus Logic과 Texas Instruments 관련 헤드폰 잭·스피커 앰프 드라이버, I2S 주변장치, Apple DMA 컨트롤러 변경이 이미 병합됨
  • 이 플랫폼의 스피커 보호는 TI 앰프가 I2S로 전압·전류를 SoC에 보내고, 스피커의 Thiele/Small Parameters와 함께 보이스 코일 온도를 계산하는 구조를 가짐
    • macOS에서는 CoreAudio가, Linux에서는 speakersafetyd가 이를 맡음
  • 여러 앰프의 data transmit 핀이 직렬 연결되고 좌우 라인이 OR 결합되는 구조에서는, 한쪽이 전송할 때 다른 쪽이 logic low를 보장해야 하므로 bus keeper 설정이 필요함
  • 기존에는 앰프 칩 드라이버와 전용 Devicetree 바인딩으로 bus keeper를 다뤘지만, upstream에는 지나치게 제한적이어서 범용 API로 바뀜
    • 이제 어떤 ASoC 컴포넌트든 설정 가능한 bus keeper 존재를 노출할 수 있고, platform 드라이버가 런타임에 필요한 설정을 적용할 수 있음
    • 이 패치셋은 Linux 7.1에 병합됨
  • Apple 전용 변형 칩 지원도 계속 넓어지고 있음
    • TI 스피커 앰프는 TAS2764, TAS2770 upstream 드라이버에 비교적 무리 없이 Apple 변형 지원을 추가함
    • CS42L84는 CS42L42와 차이가 커서 별도 Linux 드라이버가 필요했고, 이미 upstream 반영됨
  • macOS 추적만 기준으로 삼으면 macOS가 쓰는 기능만 노출되는 한계가 있었고, CS42L84도 처음에는 48kHz와 96kHz만 지원하게 됨
    • 이 제약은 PipeWire가 다른 스트림을 리샘플링하게 만들어 CPU와 배터리를 더 쓰게 하고 음질도 떨어뜨림
  • CS42L42 데이터시트의 다른 공통 샘플레이트 값을 CS42L84 드라이버에 적용한 결과, 헤드폰 잭 입력·출력 모두에서 44.1, 88.2, 176.4, 192kHz 하드웨어 지원이 동작함
    • 해당 패치는 upstream에 제출돼 Linux 7.1에 병합됐고, Asahi kernel 6.19.9에도 백포트됨

M3 지원 확대

  • Asahi 커널 트리에는 M3 기기용 추가 하드웨어 활성화 패치도 들어가고 있음
  • 포함 범위는 PCIe, MacBook 키보드와 트랙패드, SMC 기반 RTC와 reboot controller, NVMe controller까지 확장됨
  • Michael Reeves와 Alyssa Milburn의 작업으로 M3의 Linux 지원 수준은 첫 Asahi Linux alpha for M1과 대략 비슷한 단계까지 올라옴
  • Asahi Installer로 M3 설치를 바로 열 준비는 아직 끝나지 않았고, 계속 진척 중임

Fedora Asahi Remix 44

  • Fedora Asahi Remix 43 지연에도 불구하고, Fedora Asahi Remix 44는 4월 28일 Fedora Linux 44와 같거나 며칠 이내 시점에 릴리스할 계획을 유지함
  • 새 KDE Plasma 기반 설치는 Plasma 6.6의 새 기능을 활용하게 됨
    • Plasma Setup이 기존 Calamares 기반 설정 마법사를 대체해 Plasma 네이티브 계정 생성·시스템 설정 흐름을 제공함
    • Plasma Login Manager가 기본 greeter와 session manager가 되어 SDDM을 대체함
  • 이 변경은 신규 설치에만 적용되며, 이전 Fedora Asahi Remix에서 업그레이드한 사용자의 설정은 바뀌지 않음
  • Fedora Asahi Remix 44는 vendored Mesa와 virglrenderer 패키지를 종료함
    • 아직 수동 전환하지 않은 사용자는 upstream Fedora 저장소의 Mesa와 virglrenderer 패키지로 자동 전환됨

후원과 인프라 지원

함께 보면 좋은 글 β

▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • CS42L84가 macOS에서는 48/96 kHz만 쓰도록 설정돼 있었는데, CS42L42 데이터시트의 다른 샘플레이트 값을 가져와 드라이버에 넣어보니 그대로 동작했다고 함
    44.1/88.2/176.4/192 kHz를 헤드폰 잭 입출력에서 지원하는 패치가 upstream에 들어갔고, 7.1에 병합됐으며 Asahi kernel 6.19.9에도 백포트돼 바로 쓸 수 있게 됨
    칩 추적과 리버스 엔지니어링이 정말 인상적임

    • 제일 놀라운 대목은 48/96 kHz만 지원하면 PipeWire가 리샘플링 때문에 CPU와 배터리를 더 쓰게 된다는 부분임
      Apple은 전력 효율에 집착하는 회사인데 왜 여전히 이렇게 두는지 궁금해짐
    • 44.1 kHz 비트 퍼펙트 CD/FLAC 재생이 가능해진 건 정말 큰 기능처럼 보임

  • Asahi 팀의 기술 글과 성과는 정말 대단하지만, 아직도 이게 별도 프로젝트로 남아 있고 kernel mainline이나 Ubuntu, Debian, Fedora 같은 주류 배포판 안에서 지속되는 형태가 아니라는 점은 조금 걱정됨
    리버스 엔지니어링 프로젝트는 80%까지는 유용한 결과를 내기 쉬워도, 일반 사용자에게 충분히 다듬어진 95% 완성도까지 가려면 거의 같은 수준의 고되고 자잘한 작업이 더 필요함

    • Asahi도 바로 그 방향으로 많이 upstreaming하고 있음
      최근 진전이 느려진 큰 이유도 diff 수를 줄이는 데 집중했기 때문이고, 꽤 많은 작업이 이미 mainline kernel에 들어갔음
      Asahi는 새 기능을 실험하는 공간 역할도 하고 있음
    • ARM Mac 자체가 계속 움직이는 표적이라는 추가 난관도 있음
      Apple은 Asahi Linux를 위해 안정성이나 지원을 제공할 생각이 전혀 없고, PC 업계처럼 장기 호환성을 맞출 이유도 없어서 앞으로도 Asahi를 곤란하게 만드는 변경을 해도 신경 쓰지 않을 것 같음
    • Linux의 좋은 점은 자유 소프트웨어라서 주주나 수익성에 얽매이지 않는다는 데 있음
      M1 MacBook Air에서 Asahi를 기본 OS로 쓰고 있는데 꽤 만족스럽고, 잠자기 중 배터리가 시간당 1% 빠지는 같은 아쉬움이 있어도 100% 기능 완성이 아니라는 이유로 아예 없는 것보다는 지금 형태가 훨씬 나음
      굳이 일반 대중용으로 완벽하게 다듬어져 있을 필요도 크게 못 느끼겠음
    • mainline kernel 개발은 원래 다들 자기 fork에서 작업한 뒤 패치를 upstream으로 보내는 식임
      Asahi가 특별해 보이는 건 이상하고 전용 하드웨어가 많아 특수 드라이버가 많이 필요해서지, 누구도 Linus의 트리에서 직접 개발하진 않음
    • 39c3의 https://youtu.be/3OAiOfCcYFM 발표도 괜찮았음
      결국 목표는 Linux가 Apple Silicon을 네이티브 지원하게 만드는 쪽임

  • 이 프로젝트가 계속 탄력을 받았으면 좋겠음
    Apple 하드웨어 + Linux 조합이 최고의 하드웨어 위에서 돌아가는 가장 덜 망가진 OS처럼 느껴지고, macOS는 버그와 버전마다 뒤집히는 변화 때문에 점점 혼란스러움

    • Framework에 Fedora를 올려 써보면 생각이 달라질 수도 있음
      경험이 아주 매끄러웠고, 곧 나올 Framework 13 Pro는 배터리와 트랙패드도 macOS급이거나 배터리는 오히려 더 나을 거라는 기대가 있음
    • 세 주요 OS를 다 써봤는데 macOS가 가장 버그가 적고 그냥 잘 돌아가는 편이었음
      Linux는 늘 오디오나 화면 호환성 때문에 이상한 패치를 하게 됐고, Windows는 배터리 문제가 심했음
      Linux 튜닝 좋아하는 사람들 다수는 결국 더 많은 커스터마이징이 가능한 Mac 같은 경험을 원하는 것처럼 보이기도 함
    • 전반적으로는 그렇지만 MLX 주변 생태계는 꽤 강하게 뭉쳤음
      디스크 I/O가 별로고 OS도 버그가 있어도 적어도 최신 OS에서 ML이 컴파일되고 돌아감
      반면 rocm은 거의 다 된 것 같다가도 미리 빌드된 패키지나 2년 넘은 Ubuntu가 필요해서 답답함
      https://github.com/ROCm/TheRock/issues/3477
    • 최근 업무용으로 MacBook Air를 써봤는데 하드웨어 최고 수준이라는 말에는 동의하기 어려움
      5유로만 써도 더 나은 키보드를 구할 수 있을 것 같음

  • Apple이 왜 이 노력에 협조하지 않고 문서 공개를 안 하는지 이해가 잘 안 됨
    경쟁 우위나 비밀 같은 전통적인 이유는 이제 설득력이 약해 보임

    • 진짜 이유는 더 단순할 수도 있음
      Apple은 하드웨어 마진이 높아서 Linux 사용자에게 MacBook을 파는 것만으로도 이익이 나지만, 공식적으로 Linux 지원을 인정하는 순간 그게 바로 지원 책임이 됨
      kernel panic마다 Genius Bar 방문이 생기고 드라이버 버그마다 @AppleSupport가 호출될 테니, 지금처럼 비공식인 상태가 Apple 입장에선 하드웨어 판매는 챙기고 지원 부담은 피하는 가장 좋은 시나리오일 수 있음
    • 금전적 이득은 거의 없고, 하드웨어가 바뀔 때마다 Linux용 문서화 부담이 생김
      가장 시끄럽고 비판적인 사용자층이면서 규모는 작다는 점도 Apple에선 매력적이지 않을 듯함
    • 아예 우린 이 게임 안 한다고 선을 긋는 편이, 선택적 개방이나 비공개 인터페이스 호환성 파괴로 욕먹는 것보다 훨씬 쉬울 수 있음
      내부적으로도 우선순위와 무관한 논의를 계속 불러오는 걸 피할 수 있음
    • 이건 거의 right to repair와 닿아 있다고 느낌
      노트북은 여러 하드웨어 부품과 그것을 움직이는 드라이버로 이뤄져 있는데, 내가 산 게 하드웨어와 드라이버가 분리 불가능한 패키지인지, 아니면 한쪽이 망가졌을 때 다른 쪽을 직접 살릴 수 있도록 매뉴얼을 받아야 하는지 질문하게 됨
      드라이버는 기어나 모터처럼 닳지 않는다고 Apple은 주장할 수 있겠지만, 그렇다고 작동 원리를 알 권리까지 사라지는 건 아니라고 봄
      언젠가 /System/Trackpad.kext가 우주선에 맞아 날아가서 직접 드라이버를 써야 한다며 법정에서 문서를 요구하는 시험 사례가 나와도 이상하지 않을 듯함
    • 맞는 말 같음
      Apple이 이걸 지원하는 건 쉬운 일일 텐데, 커뮤니티에서 얻을 호의도 상당할 것 같음

  • Mac 같은 기본 경험에 초점을 둔 Asahi Remix 스핀이 있으면 관심이 있을지 궁금함
    cmd를 주 수정키로 쓰고, Mac식 단축키와 테마, 제스처를 기본으로 맞춰주는 식임
    아무 배포판이든 손보면 되지만, 잘 큐레이션된 기본값은 또 다른 가치가 있음

    • cmd를 “주 수정키”로 삼는 건 애매함
      일반적인 X/Wayland 환경에서는 이미 DE 기능 쪽은 Cmd가 중심이고, 앱 수준에서는 Ctrl이 중심이라 그걸 바꾸면 겹치는 부분이 많이 생김
    • KDE에서 꽤 비슷하게 맞춰놓는 데 성공했음
      Claude Code에게 구현해달라고 했더니 웹 검색해서 설정 파일까지 만들어줬음
    • Cmd 중심 키맵은 사실상 진 싸움에 가깝다고 봄
      여러 번 시도해봤지만 결국 Ctrl 생활을 받아들였고 마지막 MacBook도 팔았음

  • MacBook Pro + Linux라는 꿈의 개발 머신을 먼저 현실로 만드는 쪽이 하드웨어일지 소프트웨어일지 궁금함
    Asahi가 소프트웨어 측에서 먼저 도달할지, Framework가 하드웨어 측에서 먼저 도달할지 지켜보게 됨

  • MacBook Neo + Asahi 조합이 나오면 정말 강력할 듯함

  • M3 지원이 upstream 백로그를 처리하고 툴링을 개선하면서 착실히 진행되는 모습이 반가움
    PCIe, MacBook 키보드와 트랙패드, SMC 기반 RTC와 reboot controller, NVMe controller 지원 패치가 Asahi kernel tree에 들어가고 있고, 이로써 M3의 Linux 지원 수준이 대략 M1용 첫 Asahi Linux alpha와 비슷한 단계까지 올라옴

    • 이 속도라면 M6 출시 즈음에야 겨우 쓸만해질지도 모르겠음

  • 이런 프로젝트 리포트에서 계속 돌파구가 나오고, 실제 사용자가 어디서 불편을 겪는지 정확히 짚고 있다는 건 Asahi 팀이 정말 노련하다는 뜻처럼 보임
    조만간 Asahi로 다시 완전히 돌아가고 싶어짐

  • M3 alpha 근접 소식은 정말 훌륭하고, 앞으로 M4도 기대됨
    반면 Apple이 올해나 내년에 macOS에 또 무슨 일을 벌일지는 전혀 기대되지 않음

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.