- Hỗ trợ Linux cho Apple Silicon đang đồng thời tiến triển trên nhiều mặt: tự động hóa trình cài đặt, quản lý điện năng, âm thanh, hiển thị và cả kích hoạt M3
- Asahi Installer đã được thay đổi để tách manifest image khỏi codebase và đưa vào triển khai bằng GitHub workflow, nhờ đó có thể cập nhật thường xuyên hơn; bản 0.8.0 bổ sung cập nhật m1n1 stage 1, hỗ trợ cài đặt Mac Pro và chế độ cập nhật firmware
- Firmware hiệu chuẩn ALS giờ có thể được trích xuất từ macOS và cập nhật lại ngay cả sau khi cài đặt; hiện tượng ngắt quãng âm thanh Bluetooth đã biến mất nhờ hỗ trợ lệnh Broadcom coexistence; hỗ trợ PMP giúp giảm khoảng 0.5W điện năng nhàn rỗi trên M1 Pro
- Hỗ trợ VRR vẫn chưa thể được phơi bày đúng cách cho userspace do các ràng buộc của Apple DCP, nhưng khi pull request được hợp nhất thì có thể cưỡng bức bật bằng tham số mô-đun kernel; công việc upstream cho audio stack cũng đã bổ sung API bus keeper dùng chung và hỗ trợ thêm các sample rate cho CS42L84
- Phạm vi hỗ trợ M3 đã mở rộng tới PCIe, thiết bị nhập liệu, RTC, reboot controller và NVMe; Fedora Asahi Remix 44 vẫn giữ kế hoạch phát hành đồng thời với Fedora 44 cùng quy trình cài đặt mới dựa trên Plasma
Tự động hóa trình cài đặt và cập nhật firmware
- Asahi Installer gần như không được cập nhật thường xuyên trong suốt gần 2 năm, do quy trình phát hành thủ công và phụ thuộc vào quyền quản trị CDN, khiến chu kỳ cập nhật kéo dài; các thay đổi tích lũy kể từ thẻ tháng 6/2024 cũng đã rất lớn
- Với cài đặt chỉ dùng UEFI, chỉ có m1n1 stage 1, Devicetree và U-Boot được cài đặt, nên nếu Devicetree đi kèm trong bundle của trình cài đặt lệch với giá trị mà kernel mong đợi thì việc khởi động có thể bị chặn hoàn toàn
- Trong quá trình upstream, các Devicetree binding đã thay đổi và sự không khớp này tiếp tục tích tụ; ở kernel 6.18, các thay đổi liên quan đến Apple USB tăng mạnh đến mức không thể khởi động live media bằng 6.18 trở lên
- Manifest image có thể cài đặt đã được tách sang
asahi-installer-data, cho phép cập nhật độc lập với codebase của trình cài đặt
- Việc phát hành
asahi-installer giờ đã được tự động hóa bằng GitHub workflow
- Bản 0.8.0 mới nhất đã nâng m1n1 stage 1 đi kèm lên 1.5.2, đồng thời bổ sung hỗ trợ cài đặt Mac Pro và chế độ cập nhật firmware
ALS và trích xuất firmware
- Trong môi trường True Tone của Apple, không chỉ độ sáng môi trường mà cả đặc tính màu của ánh sáng cũng phải được đo, vì vậy việc xử lý dữ liệu ALS và độ chính xác hiệu chuẩn trở nên quan trọng
- Bản thân AOP và driver ALS đã hoạt động, nhưng nếu không có dữ liệu hiệu chuẩn thì độ chính xác của dữ liệu ALS thô do AOP xuất ra sẽ thấp
- Dữ liệu hiệu chuẩn này là một binary blob phải được nạp lên AOP khi chạy; do không thể phân phối lại nên phải lấy từ macOS trong lúc cài đặt
- Asahi Installer thu thập firmware cần thiết cho Linux rồi lưu vào EFI System Partition, sau đó mô-đun Dracut sẽ mount chúng vào các thư mục con dưới
/lib/firmware/ để driver có thể tìm thấy
- Để tránh tình huống cần thêm firmware sau khi đã cài đặt xong, trình cài đặt đã được thay đổi để hỗ trợ tự động cập nhật vendor firmware package
- Bắt đầu từ ALS, người dùng có thể khởi động vào macOS hoặc macOS Recovery, chạy lại trình cài đặt và làm theo lời nhắc để cập nhật firmware cần thiết
- Để dùng hỗ trợ ALS và các nâng cấp firmware về sau, cần Asahi kernel 6.19 trở lên và
iio-sensor-proxy
Quản lý điện năng và PMP
- Mức tiêu thụ điện khi nhàn rỗi vẫn là vấn đề kéo dài, đặc biệt trên các SoC Pro/Max/Ultra, và quản lý điện năng trên các nền tảng này có cấu trúc phức tạp với PMGR và PMP gắn chặt với nhau
- PMGR chịu trách nhiệm bật và tắt các power domain của SoC, còn PMP xử lý các báo cáo trạng thái điện năng được truyền qua bộ nhớ chia sẻ giữa các khối SoC và các lõi ứng dụng
- Nếu PMP không khởi động thì sẽ không đọc được các báo cáo này và một số chức năng quản lý điện năng cũng sẽ không hoạt động
- Driver hỗ trợ PMP do chaos_princess xây dựng giúp PMP nhận được báo cáo từ các khối SoC và PMGR, qua đó đạt mức giảm khoảng 0.5W ở trạng thái nhàn rỗi trên MacBook Pro M1 Pro 14 inch
- Mức này tương đương giảm khoảng 20% điện năng nhàn rỗi
- Dù vẫn cần thêm công việc để đạt thời gian nhàn rỗi/ngủ tương đương macOS, thay đổi lần này đã là một bước tiến lớn
- M1 tiêu chuẩn sử dụng biến thể PMP cũ không tương thích với các thế hệ sau, và dd-dreams đang triển khai phần hỗ trợ đó
- PMP vẫn chưa được kiểm chứng trên mọi thiết bị được hỗ trợ và cũng chưa có kế hoạch bật mặc định trước khi được hợp nhất upstream
- Người dùng có thể sửa Devicetree có thể bật bằng cách định nghĩa
APPLE_USE_PMP trong DTS của thiết bị
Sửa lỗi ngắt quãng âm thanh Bluetooth
- Bluetooth và WiFi cùng dùng chung băng tần 2.4GHz nên rất dễ nhiễu lẫn nhau, và các kết nối đòi hỏi độ trễ thấp cùng tính liên tục như luồng âm thanh cần được ưu tiên cao hơn
- Thiết lập coexistence của Broadcom được xử lý bằng lệnh mở rộng vendor-specific của Bluetooth HCI, nhưng kernel Linux upstream không hỗ trợ nên đã gây mất gói âm thanh khi quét Bluetooth
- Nếu KDE Connect kích hoạt quét Bluetooth thì có thể xảy ra hiện tượng rớt âm thanh
- chaos_princess đã thêm hỗ trợ lệnh này vào Bluetooth stack của kernel, còn BlueZ đánh dấu mọi luồng âm thanh là high priority, nên các lệnh cần thiết trong lúc streaming sẽ được kích hoạt tự động
- Kết quả là hiện tượng dropout âm thanh Bluetooth không còn xảy ra nữa
DCP và VRR
- Giao diện firmware DCP rất lớn và không ổn định giữa các phiên bản; trong thời gian qua, sau khi hỗ trợ hiển thị cơ bản hoàn tất thì các hạng mục phần cứng khác được ưu tiên hơn, nên những tính năng như VRR vẫn còn bỏ ngỏ
- Hỗ trợ VRR đòi hỏi đầy đủ việc trao đổi gói đặc biệt giữa display controller và màn hình, điều chỉnh vertical blanking theo thời điểm hiển thị frame, quảng bá VRR capability của màn hình, và tích hợp với KMS
- Trong quá trình theo dõi, người ta phát hiện một tham số DCP từng được đặt về 0 khi cấp nguồn cho màn hình ngoài thực ra lại chuyển giữa
0x300000 và 0x0 khi bật/tắt VRR
- Màn hình thử nghiệm có tần số quét tối thiểu là 48Hz, và trong định dạng fixed-point của DCP thì 48 là
0x300000
- Tham số này không phải để phục vụ power sequence mà là công tắc tần số quét tối thiểu của VRR; nếu đặt 0 trước modeset thì sẽ dẫn đến vô hiệu hóa VRR
- Màn hình tích hợp ProMotion trên MacBook Pro cũng được kích hoạt theo cách tương tự, nhưng panel bên trong không quảng bá EDID/DisplayID, nên driver Linux phải nhận biết đó là LCD nội bộ và thiết lập tĩnh các thuộc tính cần thiết
- VESA DisplayPort Adaptive Sync và KMS API không cho phép yêu cầu modeset khi chuyển trạng thái VRR, nhưng Apple DCP lại không thể tránh được điều đó
- Vì ràng buộc này, VRR không thể được phơi bày đúng cách cho userspace và KWin cũng sẽ bỏ qua kiểu giao diện như vậy
- Hiện tại, khi pull request được hợp nhất, có thể bật VRR cưỡng bức bằng tham số mô-đun kernel
appledrm.force_vrr
- Nếu màn hình hỗ trợ VRR thì DCP sẽ dùng VRR mà không thông báo cho KMS hay compositor
- Trên KWin nó hoạt động tốt, nhưng với các compositor khác trải nghiệm có thể khác
- Phía HDMI thì không cấm modeset giữa các lần chuyển VRR, và các display controller khác như Intel cũng hoạt động theo cách tương tự
- Ở upstream hiện vẫn đang thảo luận giữa hướng luôn bật chế độ VRR hoặc cho phép modeset khi chuyển đổi; khi hướng đi được chốt, VRR sẽ được phơi bày theo cách như mong đợi
Upstream audio stack và mở rộng sample rate
- Công việc upstream cho toàn bộ audio stack vẫn đang tiếp tục; các driver liên quan tới jack tai nghe và speaker amp của Cirrus Logic và Texas Instruments, các thiết bị ngoại vi I2S và các thay đổi ở Apple DMA controller đã được hợp nhất
- Cơ chế bảo vệ loa trên nền tảng này hoạt động bằng cách amp TI gửi điện áp và dòng điện tới SoC qua I2S, rồi kết hợp với Thiele/Small Parameters của loa để tính nhiệt độ voice coil
- Trên macOS việc này do CoreAudio đảm nhiệm, còn trên Linux là
speakersafetyd
- Trong cấu trúc mà chân data transmit của nhiều amp được mắc nối tiếp và các đường trái/phải được OR với nhau, khi một bên truyền thì bên kia phải bảo đảm logic low, nên cần thiết lập bus keeper
- Trước đây bus keeper được xử lý bằng driver chip amp và Devicetree binding riêng, nhưng cách đó quá hạn chế đối với upstream nên đã được đổi thành API dùng chung
- Giờ đây bất kỳ thành phần ASoC nào cũng có thể phơi bày sự hiện diện của bus keeper có thể cấu hình, và driver nền tảng có thể áp dụng thiết lập cần thiết tại runtime
- Bộ patch này đã được hợp nhất vào Linux 7.1
- Hỗ trợ cho các biến thể chip riêng của Apple cũng đang tiếp tục được mở rộng
- Với amp loa TI, hỗ trợ biến thể Apple được thêm vào các driver upstream TAS2764 và TAS2770 một cách tương đối suôn sẻ
- CS42L84 khác biệt đáng kể so với CS42L42 nên cần một driver Linux riêng, và nó đã được đưa upstream
- Nếu chỉ dựa vào truy vết macOS thì sẽ bị giới hạn ở đúng những chức năng macOS sử dụng; vì vậy CS42L84 ban đầu cũng chỉ hỗ trợ 48kHz và 96kHz
- Ràng buộc này buộc PipeWire phải resample các luồng khác, làm tăng tiêu thụ CPU và pin, đồng thời giảm chất lượng âm thanh
- Khi áp dụng các giá trị sample rate thông dụng khác trong datasheet của CS42L42 vào driver CS42L84, hỗ trợ phần cứng cho 44.1, 88.2, 176.4, 192kHz đã hoạt động ở cả đầu vào và đầu ra của jack tai nghe
- Patch này đã được gửi lên upstream, được hợp nhất vào Linux 7.1 và cũng đã được backport sang Asahi kernel 6.19.9
Mở rộng hỗ trợ M3
- Cây kernel của Asahi cũng đang nhận thêm các bản vá kích hoạt phần cứng cho thiết bị M3
- Phạm vi hiện bao gồm PCIe, bàn phím và trackpad MacBook, RTC dựa trên SMC, reboot controller và cả NVMe controller
- Nhờ công việc của Michael Reeves và Alyssa Milburn, mức độ hỗ trợ Linux trên M3 hiện đã đạt đến giai đoạn xấp xỉ tương đương với bản alpha Asahi Linux đầu tiên cho M1
- Việc mở cài đặt trực tiếp cho M3 trong Asahi Installer vẫn chưa sẵn sàng và công việc vẫn đang tiếp tục
Fedora Asahi Remix 44
- Bất chấp việc Fedora Asahi Remix 43 bị trì hoãn, Fedora Asahi Remix 44 vẫn giữ kế hoạch phát hành vào cùng ngày hoặc trong vòng vài ngày sau Fedora Linux 44 ngày 28/4
- Trình cài đặt mới dựa trên KDE Plasma sẽ tận dụng các tính năng mới trong Plasma 6.6
- Plasma Setup sẽ thay thế trình hướng dẫn thiết lập dựa trên Calamares trước đây, cung cấp luồng tạo tài khoản và thiết lập hệ thống theo kiểu native của Plasma
- Plasma Login Manager sẽ trở thành greeter và session manager mặc định, thay cho SDDM
- Thay đổi này chỉ áp dụng cho cài đặt mới; cấu hình của những người dùng nâng cấp từ Fedora Asahi Remix cũ sẽ không bị thay đổi
- Fedora Asahi Remix 44 sẽ chấm dứt các gói Mesa và virglrenderer được vendored
- Những người dùng chưa chuyển thủ công sẽ được tự động chuyển sang các gói Mesa và virglrenderer từ kho upstream của Fedora
Tài trợ và hỗ trợ hạ tầng
1 bình luận
Ý kiến trên Hacker News
CS42L84 trên macOS được cấu hình chỉ dùng 48/96 kHz, nhưng khi lấy các giá trị sample rate khác từ datasheet của CS42L42 đưa vào driver thì nó vẫn hoạt động nguyên vẹn
Bản vá hỗ trợ 44.1/88.2/176.4/192 kHz cho ngõ vào/ra jack tai nghe đã được đưa upstream, hợp nhất vào 7.1, đồng thời cũng được backport sang Asahi kernel 6.19.9 để có thể dùng ngay
Việc lần theo chip và reverse engineering thực sự rất ấn tượng
Apple là công ty ám ảnh với hiệu quả năng lượng, nên thật khó hiểu vì sao họ vẫn để như vậy
Các bài viết kỹ thuật và thành quả của đội Asahi thực sự rất xuất sắc, nhưng vẫn hơi đáng lo khi dự án này còn là một dự án riêng, thay vì tồn tại bền vững ngay trong kernel mainline hay các bản phân phối chủ đạo như Ubuntu, Debian, Fedora
Các dự án reverse engineering có thể khá dễ đạt tới 80% với kết quả hữu ích, nhưng để lên tới mức hoàn thiện 95% đủ trau chuốt cho người dùng phổ thông thì lại cần gần như cùng mức độ công việc vất vả và vụn vặt thêm một lần nữa
Một lý do lớn khiến tiến độ gần đây chậm lại là vì họ tập trung giảm số lượng diff, và khá nhiều phần việc đã vào mainline kernel rồi
Asahi cũng đóng vai trò như không gian để thử nghiệm tính năng mới
Apple hoàn toàn không có ý định cung cấp sự ổn định hay hỗ trợ cho Asahi Linux, và cũng không có lý do phải giữ tương thích dài hạn như ngành PC, nên có lẽ sau này họ vẫn sẽ thản nhiên thực hiện những thay đổi gây khó cho Asahi
Tôi đang dùng Asahi làm OS mặc định trên M1 MacBook Air và khá hài lòng; dù vẫn có những điểm tiếc như pin tụt 1% mỗi giờ khi ngủ, thì trạng thái hiện tại vẫn tốt hơn rất nhiều so với không có gì chỉ vì chưa đạt 100% hoàn thiện
Tôi cũng không thấy nó nhất thiết phải được mài giũa hoàn hảo cho số đông phổ thông
Việc Asahi trông có vẻ đặc biệt chỉ là vì nó có nhiều phần cứng lạ và chuyên dụng nên cần nhiều driver riêng; không ai phát triển trực tiếp trên tree của Linus cả
Sau cùng thì mục tiêu là để Linux hỗ trợ Apple Silicon một cách native
Mong là dự án này sẽ tiếp tục giữ được đà tiến
Tổ hợp phần cứng Apple + Linux cho cảm giác như hệ điều hành ít hỏng hóc nhất đang chạy trên phần cứng tốt nhất, còn macOS thì ngày càng rối vì bug và những thay đổi đảo lộn qua từng phiên bản
Trải nghiệm rất mượt, và Framework 13 Pro sắp ra mắt được kỳ vọng sẽ có pin và trackpad đạt tầm macOS, thậm chí pin còn có thể tốt hơn
Linux thì lúc nào cũng khiến tôi phải vá vời vì audio hay tương thích màn hình, còn Windows thì gặp vấn đề pin rất nặng
Nhiều người thích tinh chỉnh Linux rốt cuộc trông như đang muốn có một trải nghiệm kiểu Mac nhưng tùy biến hơn
Dù disk I/O không tốt và OS cũng có bug, ít nhất ML vẫn biên dịch và chạy được trên OS mới nhất
Trong khi đó rocm cứ như sắp xong tới nơi rồi lại bắt phải dùng gói build sẵn hay Ubuntu từ hơn 2 năm trước, rất bực bội
https://github.com/ROCm/TheRock/issues/3477
Có cảm giác chỉ cần bỏ ra 5 euro là cũng kiếm được bàn phím tốt hơn
Tôi không thực sự hiểu vì sao Apple không hợp tác với nỗ lực này và không công khai tài liệu
Những lý do truyền thống như lợi thế cạnh tranh hay bí mật giờ có vẻ không còn thuyết phục lắm
Apple có biên lợi nhuận phần cứng cao, nên chỉ cần bán MacBook cho người dùng Linux là đã có lời; nhưng khoảnh khắc họ chính thức thừa nhận hỗ trợ Linux, điều đó ngay lập tức biến thành trách nhiệm hỗ trợ
Mỗi lần kernel panic sẽ thành một chuyến ghé Genius Bar, và mỗi lỗi driver lại kéo @AppleSupport vào, nên với Apple, trạng thái không chính thức như hiện tại có thể là kịch bản tốt nhất: vẫn bán được phần cứng mà tránh được gánh nặng hỗ trợ
Đây cũng là một nhóm người dùng vừa nhỏ vừa ồn ào và hay chỉ trích nhất, nên có lẽ không hấp dẫn với Apple
Nội bộ họ cũng tránh được việc liên tục phải tranh luận về những ưu tiên không liên quan
Laptop được tạo nên từ nhiều linh kiện phần cứng và các driver vận hành chúng; điều đó khiến tôi tự hỏi liệu thứ mình mua là một gói phần cứng và driver không thể tách rời, hay khi một bên hỏng thì tôi phải được nhận tài liệu để tự cứu bên còn lại
Apple có thể lập luận rằng driver không hao mòn như bánh răng hay động cơ, nhưng điều đó không có nghĩa là quyền được biết cách nó hoạt động cũng biến mất
Sẽ không lạ nếu một ngày nào đó xuất hiện vụ kiện thử nghiệm, nơi ai đó nói /System/Trackpad.kext đã bị tàu vũ trụ bắn trúng và họ phải tự viết driver nên cần tài liệu trước tòa
Việc Apple hỗ trợ chuyện này hẳn không khó, mà thiện cảm họ nhận lại từ cộng đồng cũng sẽ khá lớn
Tôi tự hỏi liệu có ai hứng thú với một bản spin Asahi Remix tập trung vào trải nghiệm mặc định kiểu Mac không
Kiểu lấy cmd làm phím bổ trợ chính, dùng sẵn phím tắt và theme phong cách Mac, cùng các gesture mặc định tương tự
Dĩ nhiên bản phân phối nào cũng có thể chỉnh như vậy, nhưng những giá trị mặc định được tuyển chọn kỹ vẫn có giá trị riêng
Trong môi trường X/Wayland thông thường, các chức năng cấp DE vốn đã xoay quanh Cmd, còn ở cấp ứng dụng thì lại xoay quanh Ctrl, nên nếu đổi sẽ phát sinh khá nhiều chồng chéo
Tôi nhờ Claude Code triển khai, và nó đã tự tìm web rồi tạo cả file cấu hình
Tôi thử nhiều lần rồi, cuối cùng vẫn chấp nhận cuộc sống với Ctrl và bán luôn chiếc MacBook cuối cùng
Tôi tò mò không biết cỗ máy phát triển trong mơ MacBook Pro + Linux sẽ thành hiện thực trước từ phía phần cứng hay phần mềm
Sẽ thú vị khi theo dõi xem Asahi có chạm đích trước từ phía phần mềm, hay Framework sẽ làm được trước từ phía phần cứng
Nếu có tổ hợp MacBook Neo + Asahi thì sẽ thực sự rất mạnh
Thật vui khi thấy hỗ trợ M3 đang tiến triển đều đặn trong lúc xử lý backlog upstream và cải thiện tooling
Các patch hỗ trợ PCIe, bàn phím và trackpad MacBook, RTC dựa trên SMC và reboot controller, cùng NVMe controller đang được đưa vào Asahi kernel tree; nhờ đó mức hỗ trợ Linux cho M3 đã lên tới khoảng ngang với bản alpha Asahi Linux đầu tiên cho M1
Việc các báo cáo dự án kiểu này liên tục đưa ra đột phá, đồng thời chỉ rất chính xác chỗ người dùng thực tế gặp khó khăn, cho thấy đội Asahi thực sự rất lão luyện
Khiến tôi muốn sớm quay lại dùng Asahi hoàn toàn một lần nữa
Tin M3 gần chạm mốc alpha thực sự rất tuyệt, và giờ lại càng mong M4 hơn
Ngược lại, tôi hoàn toàn không mong chờ xem Apple sẽ lại làm gì với macOS trong năm nay hay năm sau