- Dukungan Linux untuk Apple Silicon mengalami kemajuan di banyak sisi sekaligus, termasuk otomatisasi installer, manajemen daya, audio, display, hingga aktivasi M3
- Asahi Installer kini memisahkan manifest image dari codebase dan mengadopsi deployment workflow GitHub sehingga bisa diperbarui lebih sering; versi 0.8.0 menambahkan pembaruan m1n1 stage 1, dukungan instalasi Mac Pro, dan mode pembaruan firmware
- Firmware kalibrasi ALS kini dapat diekstrak dari macOS dan diperbarui kembali setelah instalasi; putus-putus audio Bluetooth hilang berkat dukungan perintah Broadcom coexistence, dan dukungan PMP mengurangi daya idle sekitar 0.5W pada M1 Pro
- Dukungan VRR masih belum bisa diekspos dengan benar ke userspace karena keterbatasan Apple DCP, tetapi setelah pull request digabungkan, VRR dapat dipaksa aktif lewat parameter modul kernel; pekerjaan upstream pada stack audio juga menghadirkan API bus keeper yang lebih umum serta dukungan sample rate tambahan untuk CS42L84
- Cakupan dukungan M3 telah meluas ke PCIe, perangkat input, RTC, reboot controller, dan NVMe; Fedora Asahi Remix 44 juga tetap dijadwalkan rilis seiring Fedora 44 dengan alur instalasi baru berbasis Plasma
Otomatisasi installer dan pembaruan firmware
- Asahi Installer, yang selama hampir 2 tahun jarang diperbarui, memiliki siklus update yang panjang karena prosedur rilis manual dan ketergantungan pada hak admin CDN, sehingga akumulasi perubahan sejak tag Juni 2024 juga makin besar
- Pada instalasi khusus UEFI, hanya m1n1 stage 1, Devicetree, dan U-Boot yang dipasang, sehingga jika Devicetree di dalam bundle installer tidak cocok dengan ekspektasi kernel, proses boot bisa gagal sepenuhnya
- Selama proses upstream, binding Devicetree berubah sehingga ketidakcocokan terus menumpuk, dan pada kernel 6.18 perubahan terkait Apple USB menjadi sangat banyak sehingga live media tidak lagi bisa boot dengan 6.18 atau lebih baru
- Manifest image yang dapat diinstal kini dipisahkan ke
asahi-installer-data agar bisa diperbarui secara independen dari codebase installer
- Distribusi
asahi-installer sekarang diotomatisasi lewat workflow GitHub
- Versi terbaru 0.8.0 menaikkan m1n1 stage 1 bawaan ke 1.5.2, serta menambahkan dukungan instalasi Mac Pro dan mode pembaruan firmware
ALS dan ekstraksi firmware
- Dalam lingkungan True Tone milik Apple, bukan hanya kecerahan sekitar yang harus diukur, tetapi juga karakteristik warna pencahayaan, sehingga pemrosesan data ALS dan akurasi kalibrasi menjadi penting
- AOP dan driver ALS sendiri sebenarnya sudah berfungsi, tetapi tanpa data kalibrasi, akurasi data mentah ALS yang dihasilkan AOP menjadi rendah
- Data kalibrasi ini adalah blob biner yang harus diunggah ke AOP saat runtime, dan karena tidak dapat didistribusikan ulang, data ini harus diambil dari macOS saat instalasi
- Asahi Installer mengumpulkan firmware yang dibutuhkan Linux lalu menyimpannya di EFI System Partition, dan modul Dracut me-mount firmware itu ke subdirektori di bawah
/lib/firmware/ agar bisa ditemukan driver
- Untuk mencegah masalah saat firmware tambahan baru dibutuhkan setelah sistem sudah terpasang, installer kini mendukung pembaruan otomatis vendor firmware package
- Mulai dari ALS, firmware yang dibutuhkan dapat diperbarui dengan boot ke macOS atau macOS Recovery, lalu menjalankan installer lagi dan mengikuti prompt
- Untuk dukungan ALS dan pembaruan firmware setelahnya, dibutuhkan Asahi kernel 6.19 atau lebih baru serta
iio-sensor-proxy
Manajemen daya dan PMP
- Konsumsi daya saat idle terus menjadi masalah terutama pada SoC Pro/Max/Ultra, dan manajemen daya platform ini memiliki struktur kompleks yang melibatkan PMGR dan PMP sekaligus
- PMGR bertugas menyalakan dan mematikan domain daya SoC, sedangkan PMP menerima dan memproses laporan status daya yang dikirim lewat memori bersama oleh blok SoC dan core aplikasi
- Jika PMP tidak berhasil boot, ia tidak bisa membaca laporan tersebut, dan fungsi manajemen daya tertentu juga tidak akan bekerja
- Driver dukungan PMP buatan chaos_princess membuat PMP dapat menerima laporan dari blok SoC dan PMGR, dan pada MacBook Pro 14 inci M1 Pro dalam keadaan idle berhasil mencapai penghematan sekitar 0.5W
- Ini setara dengan penurunan daya idle sekitar 20%
- Untuk mencapai waktu idle dan sleep setara macOS masih diperlukan pekerjaan tambahan, tetapi perubahan kali ini sudah merupakan langkah maju yang besar
- M1 dasar memakai varian PMP lama yang tidak kompatibel dengan generasi berikutnya, dan dd-dreams sedang mengerjakan dukungannya
- PMP masih belum diuji di semua perangkat yang didukung, dan juga belum ada rencana mengaktifkannya secara default sebelum digabungkan ke upstream
- Pengguna yang dapat memodifikasi Devicetree bisa mengaktifkannya dengan mendefinisikan
APPLE_USE_PMP di DTS perangkat
Perbaikan putus-putus audio Bluetooth
- Bluetooth dan WiFi berbagi band 2.4GHz yang sama sehingga mudah saling mengganggu, dan koneksi seperti stream audio yang sensitif terhadap latensi dan kontinuitas membutuhkan prioritas lebih tinggi
- Pengaturan coexistence dari Broadcom ditangani lewat perintah ekstensi vendor-specific pada Bluetooth HCI, tetapi kernel Linux upstream tidak mendukungnya sehingga terjadi kehilangan paket audio saat pemindaian Bluetooth
- Jika KDE Connect memicu pemindaian Bluetooth, audio bisa mengalami drop
- chaos_princess menambahkan dukungan perintah ini ke stack Bluetooth kernel, dan karena BlueZ menandai semua stream audio sebagai high priority, perintah yang diperlukan akan otomatis dipicu saat streaming berlangsung
- Hasilnya, dropout audio Bluetooth tidak lagi terjadi
DCP dan VRR
- Antarmuka firmware DCP sangat besar dan tidak stabil antarversi, dan selama ini setelah dukungan display dasar tersedia, pekerjaan perangkat keras lain diprioritaskan sehingga fitur seperti VRR tertinggal
- Dukungan VRR membutuhkan pertukaran paket khusus antara display controller dan display, penyesuaian vertical blanking berdasarkan waktu tampilan frame, pengiklanan kemampuan VRR dari display, serta integrasi dengan KMS
- Dalam proses pelacakan, terungkap bahwa parameter DCP yang sebelumnya diatur ke 0 saat menyalakan daya display eksternal sebenarnya berubah antara
0x300000 dan 0x0 saat VRR dinyalakan atau dimatikan
- Refresh rate minimum display uji adalah 48Hz, dan dalam format fixed-point DCP, 48 direpresentasikan sebagai
0x300000
- Parameter ini bukan untuk power sequencing, melainkan toggle refresh rate minimum VRR, dan jika diisi 0 sebelum modeset maka VRR akan dinonaktifkan
- Display internal ProMotion pada MacBook Pro juga diaktifkan dengan cara yang sama, tetapi karena panel internal tidak mengiklankan EDID/DisplayID, driver Linux harus menentukan bahwa itu LCD internal lalu menetapkan properti yang diperlukan secara statis
- VESA DisplayPort Adaptive Sync dan KMS API tidak mengizinkan transisi status VRR yang memerlukan modeset, tetapi Apple DCP tidak bisa menghindarinya
- Karena keterbatasan ini, VRR tidak dapat diekspos dengan benar ke userspace, dan KWin juga akan mengabaikan antarmuka seperti itu
- Saat ini, setelah pull request digabungkan, VRR paksa dapat diaktifkan lewat parameter modul kernel
appledrm.force_vrr
- Jika display mendukung VRR, DCP akan menggunakan VRR tanpa memberi tahu KMS atau compositor
- Ini berjalan baik di KWin, tetapi pengalaman pada compositor lain bisa berbeda
- Di sisi HDMI, modeset tidak dilarang saat transisi VRR, dan display controller lain seperti milik Intel juga bekerja dengan cara serupa
- Di upstream saat ini sedang dibahas apakah mode VRR akan selalu dinyalakan atau apakah modeset akan diizinkan saat transisi, dan setelah arahnya diputuskan VRR akan diekspos sesuai cara yang diharapkan
Upstream stack audio dan perluasan sample rate
- Pekerjaan upstream untuk seluruh stack audio terus berlanjut, dan driver headphone jack serta speaker amp terkait Cirrus Logic dan Texas Instruments, periferal I2S, serta perubahan pada Apple DMA controller sudah digabungkan
- Proteksi speaker di platform ini bekerja dengan cara amplifier TI mengirim tegangan dan arus ke SoC lewat I2S, lalu suhu voice coil dihitung bersama Thiele/Small Parameters speaker
- Di macOS ini ditangani CoreAudio, sedangkan di Linux ditangani
speakersafetyd
- Pada struktur di mana pin data transmit dari beberapa amplifier dirangkai seri dan jalur kiri/kanan digabung dengan OR, diperlukan pengaturan bus keeper agar sisi yang tidak sedang mengirim tetap menjamin logic low
- Sebelumnya bus keeper ditangani lewat driver chip amplifier dan binding Devicetree khusus, tetapi di upstream pendekatan itu terlalu terbatas sehingga diubah menjadi API umum
- Sekarang komponen ASoC apa pun dapat mengekspos keberadaan bus keeper yang bisa dikonfigurasi, dan driver platform dapat menerapkan pengaturan yang diperlukan saat runtime
- Patchset ini digabungkan ke Linux 7.1
- Dukungan untuk chip varian khusus Apple juga terus diperluas
- Speaker amp TI menambahkan dukungan varian Apple ke driver upstream TAS2764 dan TAS2770 tanpa banyak kesulitan
- CS42L84 cukup berbeda dari CS42L42 sehingga memerlukan driver Linux terpisah, dan itu sudah masuk upstream
- Jika hanya menjadikan hasil pelacakan macOS sebagai acuan, ada keterbatasan karena hanya fitur yang dipakai macOS yang akan terekspos, dan CS42L84 awalnya juga hanya mendukung 48kHz dan 96kHz
- Batasan ini membuat PipeWire harus melakukan resampling pada stream lain, yang meningkatkan penggunaan CPU dan baterai sekaligus menurunkan kualitas suara
- Dengan menerapkan nilai sample rate umum lain dari datasheet CS42L42 ke driver CS42L84, dukungan hardware 44.1, 88.2, 176.4, 192kHz pada input dan output headphone jack berhasil berfungsi
- Patch tersebut telah diajukan ke upstream, digabungkan ke Linux 7.1, dan juga di-backport ke Asahi kernel 6.19.9
Perluasan dukungan M3
- Ke tree kernel Asahi juga terus masuk patch aktivasi perangkat keras tambahan untuk perangkat M3
- Cakupannya telah meluas hingga PCIe, keyboard dan trackpad MacBook, RTC berbasis SMC dan reboot controller, serta NVMe controller
- Berkat pekerjaan Michael Reeves dan Alyssa Milburn, tingkat dukungan Linux untuk M3 kini sudah mencapai tahap yang kira-kira setara dengan alpha Asahi Linux pertama untuk M1
- Persiapan untuk langsung membuka instalasi M3 lewat Asahi Installer masih belum selesai, dan pekerjaan masih terus berlanjut
Fedora Asahi Remix 44
- Meski Fedora Asahi Remix 43 terlambat, Fedora Asahi Remix 44 tetap direncanakan rilis pada 28 April bersamaan dengan Fedora Linux 44 atau dalam selang beberapa hari
- Instalasi baru berbasis KDE Plasma akan memanfaatkan fitur baru di Plasma 6.6
- Plasma Setup menggantikan wizard konfigurasi berbasis Calamares sebelumnya dan menyediakan alur pembuatan akun serta pengaturan sistem yang native Plasma
- Plasma Login Manager menjadi greeter dan session manager default, menggantikan SDDM
- Perubahan ini hanya berlaku untuk instalasi baru, dan pengaturan pengguna yang melakukan upgrade dari Fedora Asahi Remix sebelumnya tidak akan berubah
- Fedora Asahi Remix 44 menghentikan paket Mesa dan virglrenderer yang divendorkan
- Pengguna yang belum beralih secara manual akan otomatis dipindahkan ke paket Mesa dan virglrenderer dari repositori Fedora upstream
Dukungan sponsor dan infrastruktur
1 komentar
Komentar Hacker News
CS42L84 di macOS dikonfigurasi agar hanya memakai 48/96 kHz, tetapi ketika nilai sample rate lain dari datasheet CS42L42 diambil lalu dimasukkan ke driver, ternyata langsung berfungsi
Patch yang menambahkan dukungan 44.1/88.2/176.4/192 kHz untuk input/output jack headphone sudah masuk upstream, digabungkan ke 7.1, dan juga di-backport ke Asahi kernel 6.19.9 sehingga bisa langsung dipakai
Pelacakan chip dan reverse engineering-nya benar-benar mengesankan
Apple adalah perusahaan yang terobsesi pada efisiensi daya, jadi jadi penasaran kenapa mereka masih membiarkannya seperti ini
Tulisan teknis dan pencapaian tim Asahi benar-benar luar biasa, tetapi tetap agak mengkhawatirkan bahwa ini masih menjadi proyek terpisah, bukan sesuatu yang berkelanjutan di kernel mainline atau distro arus utama seperti Ubuntu, Debian, dan Fedora
Proyek reverse engineering mungkin relatif mudah menghasilkan hasil yang berguna sampai 80%, tetapi untuk mencapai tingkat kematangan 95% yang cukup rapi bagi pengguna umum biasanya masih butuh pekerjaan melelahkan dan remeh-temeh dalam jumlah hampir sama banyak
Salah satu alasan besar kenapa progres belakangan terasa melambat adalah karena mereka fokus mengurangi jumlah diff, dan cukup banyak pekerjaan sudah masuk ke kernel mainline
Asahi juga berperan sebagai ruang untuk bereksperimen dengan fitur baru
Apple sama sekali tidak berniat memberikan stabilitas atau dukungan demi Asahi Linux, dan juga tidak punya alasan untuk menjaga kompatibilitas jangka panjang seperti industri PC, jadi ke depan pun mereka kemungkinan tidak akan peduli jika membuat perubahan yang menyulitkan Asahi
Saya memakai Asahi sebagai OS utama di M1 MacBook Air dan cukup puas; meski ada kekurangan seperti baterai berkurang 1% per jam saat sleep, bentuknya yang sekarang jauh lebih baik daripada tidak ada sama sekali hanya karena belum 100% selesai
Saya juga tidak terlalu merasa ini harus dipoles sempurna untuk konsumsi massa
Yang membuat Asahi tampak istimewa adalah karena ada banyak perangkat keras aneh dan khusus sehingga butuh banyak driver khusus; tidak ada yang benar-benar mengembangkan langsung di tree milik Linus
Pada akhirnya tujuannya adalah membuat Linux mendukung Apple Silicon secara native
Semoga proyek ini terus mendapat momentum
Kombinasi perangkat keras Apple + Linux terasa seperti OS yang paling tidak rusak di atas perangkat keras terbaik, sementara macOS makin terasa kacau karena bug dan perubahan yang bolak-balik di setiap versi
Pengalamannya sangat mulus, dan ada harapan Framework 13 Pro yang akan datang nanti akan setara dengan macOS dalam baterai dan trackpad, atau bahkan lebih baik di sisi baterai
Di Linux saya selalu harus memasang patch aneh karena kompatibilitas audio atau layar, sedangkan di Windows masalah baterainya parah
Banyak orang yang suka mengutak-atik Linux pada akhirnya juga tampak menginginkan pengalaman seperti Mac yang bisa dikustomisasi lebih jauh
Walau disk I/O kurang bagus dan OS-nya juga punya bug, setidaknya ML bisa dikompilasi dan dijalankan di OS terbaru
Sebaliknya, rocm sering terasa hampir jadi tetapi kemudian tetap membutuhkan paket prebuilt atau Ubuntu yang sudah lebih dari 2 tahun usianya, yang sangat membuat frustrasi
https://github.com/ROCm/TheRock/issues/3477
Rasanya dengan keluar 5 euro saja sudah bisa mendapatkan keyboard yang lebih baik
Sulit memahami kenapa Apple tidak bekerja sama dalam upaya ini dan tidak membuka dokumentasi
Alasan tradisional seperti keunggulan kompetitif atau kerahasiaan kini tampak kurang meyakinkan
Margin perangkat keras Apple tinggi, jadi mereka tetap untung hanya dengan menjual MacBook ke pengguna Linux, tetapi saat secara resmi mengakui dukungan Linux, itu langsung berubah menjadi tanggung jawab dukungan
Setiap kernel panic akan berujung kunjungan ke Genius Bar dan setiap bug driver akan memanggil @AppleSupport, jadi status tidak resmi seperti sekarang mungkin adalah skenario terbaik bagi Apple: penjualan perangkat keras tetap dapat, beban dukungan bisa dihindari
Fakta bahwa ini adalah kelompok pengguna yang paling berisik dan paling kritis sekaligus kecil skalanya juga tampaknya tidak menarik bagi Apple
Secara internal juga bisa menghindari terus munculnya diskusi yang tidak terkait prioritas
Laptop terdiri dari berbagai komponen perangkat keras dan driver yang menggerakkannya; ini memunculkan pertanyaan apakah yang saya beli adalah paket tak terpisahkan antara perangkat keras dan driver, atau apakah saya seharusnya mendapat manual agar bisa menyelamatkan salah satunya sendiri ketika yang lain rusak
Apple bisa saja berargumen bahwa driver tidak aus seperti roda gigi atau motor, tetapi itu tidak berarti hak untuk mengetahui cara kerjanya ikut hilang
Tidak akan aneh kalau suatu hari ada kasus uji di pengadilan yang menuntut dokumentasi dengan alasan /System/Trackpad.kext terkena pesawat luar angkasa dan saya harus menulis driver sendiri
Seharusnya mudah bagi Apple untuk mendukung ini, dan itikad baik yang didapat dari komunitas juga kemungkinan besar cukup besar
Saya penasaran apakah akan ada spin Asahi Remix yang berfokus pada pengalaman default ala Mac
Misalnya menjadikan cmd sebagai tombol modifier utama, lalu menyetel shortcut, tema, dan gesture ala Mac sebagai default
Distro apa pun sebenarnya bisa diutak-atik, tetapi default yang dikurasi dengan baik tetap punya nilai tersendiri
Di lingkungan X/Wayland yang umum, fungsi-fungsi DE memang sudah banyak berpusat pada Cmd, sedangkan di level aplikasi tetap berpusat pada Ctrl, jadi kalau itu diubah akan banyak area tumpang tindih
Saya minta Claude Code untuk mengimplementasikannya, lalu ia melakukan pencarian web dan bahkan membuat file konfigurasinya
Saya sudah mencoba beberapa kali, tetapi akhirnya menerima hidup dengan Ctrl dan menjual MacBook terakhir saya
Saya penasaran apakah mesin pengembangan impian berupa MacBook Pro + Linux akan lebih dulu terwujud dari sisi perangkat keras atau perangkat lunak
Menarik melihat apakah Asahi akan mencapainya lebih dulu dari sisi software, atau Framework lebih dulu dari sisi hardware
Kombinasi MacBook Neo + Asahi akan sangat kuat kalau benar-benar muncul
Menyenangkan melihat dukungan M3 terus maju dengan mantap sambil membereskan backlog upstream dan memperbaiki tooling
Patch dukungan untuk PCIe, keyboard dan trackpad MacBook, RTC berbasis SMC dan reboot controller, serta NVMe controller sedang masuk ke Asahi kernel tree, dan dengan itu tingkat dukungan Linux untuk M3 kini kira-kira sudah mencapai tahap yang setara dengan alpha pertama Asahi Linux untuk M1
Fakta bahwa laporan proyek seperti ini terus menghadirkan terobosan dan mampu menunjukkan dengan tepat di mana pengguna nyata mengalami ketidaknyamanan membuat tim Asahi terlihat benar-benar sangat berpengalaman
Rasanya jadi ingin segera kembali sepenuhnya ke Asahi
Kabar bahwa M3 sudah mendekati alpha benar-benar luar biasa, dan saya juga menantikan M4
Sebaliknya, saya sama sekali tidak menantikan apa lagi yang akan Apple lakukan pada macOS tahun ini atau tahun depan