Asahi Linux 진행 보고서 Linux 7.0

2 weeks ago 9

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로 자동화됨
- main 브랜치 푸시는 https://alx.sh/dev로 자동 빌드·업로드됨
- GitHub 태그 푸시는 https://alx.sh로 자동 배포됨
최신 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 패키지로 자동 전환됨