Asahi Linux İlerleme Raporu Linux 7.0

 (asahilinux.org)
1 puan yazan GN⁺ 3 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Apple Silicon için Linux desteği, kurucu otomasyonu, güç yönetimi, ses, ekran ve M3 etkinleştirmeye kadar birden çok alanda aynı anda ilerliyor
  • Asahi Installer, image manifestlerini kod tabanından ayırıp GitHub workflow dağıtımını devreye alarak daha sık güncellenebilir hale getirildi; 0.8.0 sürümünde m1n1 stage 1 güncellemesi, Mac Pro kurulum desteği ve firmware güncelleme modu eklendi
  • ALS kalibrasyon firmware'i artık macOS'tan çıkarılıp kurulumdan sonra da yeniden güncellenebiliyor; Bluetooth ses kopmaları Broadcom coexistence komut desteğiyle ortadan kalktı; PMP desteği ise M1 Pro'da boşta güç tüketimini yaklaşık 0.5W azalttı
  • VRR desteği, Apple DCP kısıtları nedeniyle hâlâ userspace'e düzgün biçimde sunulamıyor; ancak pull request birleştirildiğinde çekirdek modül parametresiyle zorla etkinleştirilebilecek. Ses yığını için upstream çalışmaları kapsamında bus keeper genel API'si ile CS42L84 için ek örnekleme oranı desteği de eklendi
  • M3 destek kapsamı PCIe, giriş aygıtları, RTC, reboot controller ve NVMe'ye kadar genişledi; Fedora Asahi Remix 44 ise yeni Plasma tabanlı kurulum akışıyla birlikte Fedora 44 zamanlamasına uygun çıkış planını koruyor

Kurucu otomasyonu ve firmware güncellemesi

  • Yaklaşık 2 yıl boyunca seyrek güncellenen Asahi Installer, manuel sürüm çıkarma süreci ve CDN yönetici yetkilerine bağımlılık nedeniyle uzun güncelleme döngülerine sahipti; 2024 Haziran etiketinden sonra biriken değişiklikler de büyüdü
  • Yalnızca UEFI kurulumunda sadece m1n1 stage 1, Devicetree ve U-Boot kurulduğundan, kurucu paketindeki Devicetree çekirdeğin beklediği sürümle uyuşmazsa sistemin önyüklemesi tamamen engellenebiliyor
    • upstream ilerlerken Devicetree binding'leri değiştiği için uyumsuzluklar birikti; kernel 6.18'de Apple USB ile ilgili değişiklikler arttığından, live media ile 6.18 ve üstü sürümler önyüklenemez hale geldi
  • Kurulabilir image manifestleri asahi-installer-data deposuna ayrıldı; böylece kurucu kod tabanından bağımsız olarak güncellenebiliyor
  • asahi-installer dağıtımı artık GitHub workflow ile otomatikleştiriliyor
    • main dalına yapılan push'lar otomatik olarak https://alx.sh/dev adresine derlenip yükleniyor
    • GitHub tag push'ları otomatik olarak https://alx.sh adresine dağıtılıyor
  • En güncel 0.8.0 sürümü, paketlenmiş m1n1 stage 1'i 1.5.2'ye yükseltti ve Mac Pro kurulum desteğiyle firmware güncelleme modunu ekledi

ALS ve firmware çıkarımı

  • Apple'ın True Tone ortamında yalnızca ortam parlaklığını değil, aydınlatmanın renk özelliklerini de ölçmek gerektiğinden ALS veri işleme ve kalibrasyon doğruluğu önem kazanıyor
  • AOP ve ALS sürücüsünün kendisi zaten çalışıyordu, ancak kalibrasyon verisi olmadan AOP'nin verdiği ham ALS verisinin doğruluğu düşüyordu
    • Bu kalibrasyon verisi, çalışma anında AOP'ye yüklenmesi gereken bir binary blob ve yeniden dağıtılamadığı için kurulum sırasında macOS'tan alınması gerekiyor
  • Asahi Installer, Linux'un ihtiyaç duyduğu firmware'leri toplayıp EFI System Partition'a kaydediyor; Dracut modülü de bunları /lib/firmware/ altındaki alt dizinlere mount ederek sürücünün bulmasını sağlıyor
  • Kurulum yapıldıktan sonra ek firmware gereksinimi doğması sorununu önlemek için, kurucu artık vendor firmware package otomatik güncellemesini destekliyor
    • ALS'den itibaren macOS veya macOS Recovery ile önyükleyip kurucuyu yeniden çalıştırarak istemleri takip etmek, gerekli firmware'i güncellemek için yeterli
  • ALS desteği ve sonrasındaki firmware yükseltmeleri için Asahi kernel 6.19 veya üstü ile iio-sensor-proxy gerekiyor

Güç yönetimi ve PMP

  • Boşta güç tüketimi özellikle Pro/Max/Ultra SoC'lerde süregelen bir sorundu ve bu platformların güç yönetimi, PMGR ile PMP'nin birlikte yer aldığı karmaşık bir yapıya sahip
  • PMGR, SoC güç alanlarını açıp kapatma görevini üstlenirken PMP, SoC blokları ile uygulama çekirdeklerinin paylaşımlı bellek üzerinden ilettiği güç durumu raporlarını alıp işliyor
    • PMP önyüklenmezse bu raporları okuyamıyor ve bazı güç yönetimi işlevleri de çalışmıyor
  • chaos_princess tarafından geliştirilen PMP destek sürücüsü, SoC blokları ve PMGR raporlarının PMP tarafından alınmasını sağladı ve 14 inç M1 Pro MacBook Pro'nun boşta durumunda yaklaşık 0.5W tasarruf elde etti
    • Bu, boşta güç tüketiminde yaklaşık %20 azalma anlamına geliyor
  • macOS düzeyindeki boşta ve uyku sürelerine ulaşmak için hâlâ ek çalışma gerekiyor, ancak bu değişiklik büyük bir ilerleme sayılıyor
  • Temel M1, sonraki nesillerle uyumlu olmayan eski bir PMP varyantı kullanıyor ve dd-dreams bu destek üzerinde çalışıyor
  • PMP henüz desteklenen tüm cihazlarda doğrulanmış değil ve upstream'e birleşene kadar varsayılan olarak etkinleştirilmesi planlanmıyor
    • Devicetree'yi düzenleyebilen kullanıcılar, aygıt DTS'inde APPLE_USE_PMP tanımlayarak bunu açabilir

Bluetooth ses kopmalarının düzeltilmesi

  • Bluetooth ve WiFi aynı 2.4GHz bandını paylaştığı için girişim oluşması kolaydır; ses akışları gibi gecikme ve sürekliliğin kritik olduğu bağlantılar daha yüksek öncelik gerektirir
  • Broadcom'un coexistence ayarları, Bluetooth HCI'nin vendor-specific genişletme komutları üzerinden işlenir; ancak upstream Linux çekirdeği bunu desteklemediğinden Bluetooth taraması sırasında ses paket kaybı oluşuyordu
    • KDE Connect Bluetooth taramasını tetiklediğinde ses düşmeleri yaşanabiliyordu
  • chaos_princess bu komut desteğini çekirdek Bluetooth yığınına ekledi; BlueZ ise tüm ses akışlarını high priority olarak işaretlediği için akış sırasında gerekli komut otomatik tetikleniyor
  • Sonuç olarak Bluetooth ses drop-out'ları artık yaşanmıyor

DCP ve VRR

  • DCP firmware arayüzü çok büyük, sürümler arasında kararsız ve temel ekran desteğinin ardından diğer donanım çalışmaları önceliklendirildiği için VRR gibi özellikler geride kalmıştı
  • VRR desteği için ekran denetleyicisi ile ekran arasında özel paket alışverişi, kare gösterim zamanlamasına göre vertical blanking ayarı, ekranın VRR capability ilanı ve KMS entegrasyonu gerekiyor
  • İz sürme sırasında, harici ekrana güç verilirken 0 olarak ayarlanan bir DCP parametresinin VRR açma/kapama sırasında 0x300000 ile 0x0 arasında değiştiği görüldü
    • Test ekranının minimum yenileme hızı 48Hz idi ve DCP sabit noktalı biçiminde 48, 0x300000 olarak ifade ediliyordu
    • Bu parametrenin güç sıralaması için değil, VRR minimum yenileme hızı geçişi için olduğu anlaşıldı; modeset öncesi 0 verilmesi VRR'nin devre dışı kalmasına yol açıyordu
  • MacBook Pro'nun ProMotion destekli dahili ekranı da aynı şekilde etkinleştiriliyor; ancak dahili panel EDID/DisplayID ilan etmediği için Linux sürücüsü bunun dahili LCD olduğunu anlayıp gerekli özelliği statik olarak ayarlıyor
  • VESA DisplayPort Adaptive Sync ve KMS API, VRR durum geçişlerinde modeset gerektirilmesine izin vermiyor; Apple DCP ise bundan kaçınamıyor
    • Bu kısıt nedeniyle VRR userspace'e düzgün biçimde sunulamıyor ve KWin de böyle bir arayüzü yok sayıyor
  • Şu anda pull request birleştirildiğinde appledrm.force_vrr çekirdek modül parametresiyle zorunlu VRR açılabilecek
    • Ekran VRR'yi destekliyorsa DCP, KMS veya compositor'a bildirmeden VRR kullanacak
    • KWin ile iyi çalıştı ancak diğer compositor'larda deneyim farklı olabilir
  • HDMI tarafı, VRR geçişleri arasında modeset'i yasaklamıyor ve Intel gibi diğer ekran denetleyicileri de benzer şekilde çalışıyor
    • upstream'de VRR modunu her zaman açık tutma ya da geçiş sırasında modeset'e izin verme yaklaşımları tartışılıyor; yön netleştiğinde VRR'nin beklenen biçimde sunulması planlanıyor

Ses yığını upstream ve örnekleme oranı genişlemesi

  • Tüm ses yığını için upstream çalışmaları sürüyor; Cirrus Logic ve Texas Instruments ile ilgili kulaklık jakı ve hoparlör amplifikatörü sürücüleri, I2S çevre birimleri ve Apple DMA denetleyicisi değişiklikleri zaten birleştirildi
  • Bu platformdaki hoparlör korumasında TI amplifikatörü, gerilim ve akımı I2S üzerinden SoC'ye gönderiyor; hoparlörün Thiele/Small Parameters değerleriyle birlikte voice coil sıcaklığı hesaplanıyor
  • Birden çok amplifikatörün data transmit pinlerinin seri bağlandığı ve sağ/sol hatların OR ile birleştirildiği yapıda, biri veri gönderirken diğerinin logic low'yu garanti etmesi gerektiğinden bus keeper ayarı gerekiyor
  • Daha önce bus keeper, amplifikatör çipi sürücüleri ve özel Devicetree binding'leriyle ele alınıyordu; ancak bu yaklaşım upstream için fazla kısıtlayıcı olduğundan genel bir API'ye dönüştürüldü
    • Artık herhangi bir ASoC bileşeni, yapılandırılabilir bir bus keeper bulunduğunu gösterebiliyor ve platform sürücüsü çalışma anında gerekli ayarı uygulayabiliyor
    • Bu patch set Linux 7.1'e birleştirildi
  • Apple'a özgü varyant çip desteği de genişlemeyi sürdürüyor
    • TI hoparlör amplifikatörleri için TAS2764 ve TAS2770 upstream sürücülerine Apple varyant desteği nispeten sorunsuz eklendi
    • CS42L84, CS42L42'den belirgin biçimde farklı olduğu için ayrı bir Linux sürücüsü gerekti ve bu da zaten upstream'e alındı
  • Yalnızca macOS iz sürmesine dayanmak, macOS'un kullandığı işlevlerle sınırlı kalma sorununu doğuruyordu; bu yüzden CS42L84 başlangıçta yalnızca 48kHz ve 96kHz destekliyordu
    • Bu kısıtlama, PipeWire'ın diğer akışları yeniden örneklemesine neden olarak daha fazla CPU ve pil tüketimi yaratıyor, ayrıca ses kalitesini düşürüyordu
  • CS42L42 veri sayfasındaki diğer yaygın örnekleme oranı değerleri CS42L84 sürücüsüne uygulandığında, kulaklık jakı giriş ve çıkışında 44.1, 88.2, 176.4, 192kHz donanım desteğinin çalıştığı görüldü
    • İlgili yama upstream'e gönderildi, Linux 7.1'e birleştirildi ve Asahi kernel 6.19.9'a da backport edildi

M3 desteğinin genişlemesi

  • Asahi çekirdek ağacına M3 cihazları için ek donanım etkinleştirme yamaları da giriyor
  • Kapsam PCIe, MacBook klavyesi ve trackpad, SMC tabanlı RTC ve reboot controller ile NVMe controller'a kadar genişliyor
  • Michael Reeves ve Alyssa Milburn'ün çalışmaları sayesinde M3'te Linux desteği seviyesi, ilk Asahi Linux alpha for M1 ile kabaca benzer bir aşamaya ulaştı
  • Asahi Installer üzerinden M3 kurulumunu doğrudan açmaya yönelik hazırlık henüz tamamlanmadı ve çalışmalar sürüyor

Fedora Asahi Remix 44

  • Fedora Asahi Remix 43 gecikmesine rağmen, Fedora Asahi Remix 44 Fedora Linux 44 ile aynı gün ya da 28 Nisan'dan sonraki birkaç gün içinde çıkma planını koruyor
  • Yeni KDE Plasma tabanlı kurulum, Plasma 6.6'nın yeni özelliklerinden yararlanacak
    • Plasma Setup, mevcut Calamares tabanlı kurulum sihirbazının yerini alarak Plasma'nın yerel hesap oluşturma ve sistem ayarlama akışını sunuyor
    • Plasma Login Manager, varsayılan greeter ve session manager olarak SDDM'nin yerini alıyor
  • Bu değişiklikler yalnızca yeni kurulumlara uygulanacak; önceki Fedora Asahi Remix sürümünden yükseltme yapan kullanıcıların ayarları değişmeyecek
  • Fedora Asahi Remix 44, vendored Mesa ve virglrenderer paketlerini sonlandırıyor
    • Henüz elle geçiş yapmamış kullanıcılar, upstream Fedora deposundaki Mesa ve virglrenderer paketlerine otomatik olarak geçirilecek

Destek ve altyapı yardımı

İlgili okumalar

1 yorum

 
GN⁺ 3 일 전
Hacker News yorumları

  • CS42L84 macOS'ta yalnızca 48/96 kHz kullanacak şekilde ayarlanmıştı; ancak CS42L42 veri sayfasındaki diğer örnekleme hızı değerleri alınıp sürücüye eklendiğinde aynen çalıştığı görüldü
    Kulaklık jakı giriş/çıkışında 44.1/88.2/176.4/192 kHz desteği sağlayan yama upstream'e girdi, 7.1'e birleştirildi ve Asahi kernel 6.19.9'a da backport edilerek hemen kullanılabilir hale geldi
    Çip takibi ve tersine mühendislik gerçekten etkileyici

    • En şaşırtıcı kısım, yalnızca 48/96 kHz desteği olduğunda PipeWire'ın yeniden örnekleme yüzünden daha fazla CPU ve pil tüketmesi
      Apple güç verimliliğine bu kadar takıntılı bir şirketken neden bunu hâlâ böyle bıraktığını merak ettiriyor
    • 44.1 kHz bit-perfect CD/FLAC oynatımının mümkün hale gelmesi gerçekten büyük bir özellik gibi görünüyor

  • Asahi ekibinin teknik yazıları ve başarıları gerçekten etkileyici, ancak bunun hâlâ ayrı bir proje olarak kalması ve kernel mainline ya da Ubuntu, Debian, Fedora gibi ana akım dağıtımlar içinde sürdürülen bir yapı olmaması biraz endişe verici
    Tersine mühendislik projeleri %80'e kadar faydalı sonuç üretmekte iyi olabilir, ama genel kullanıcı için yeterince cilalanmış %95 tamamlanmışlık düzeyine ulaşmak için neredeyse aynı ölçüde yorucu ve ufak tefek iş daha gerekir

    • Asahi de zaten tam olarak bu yönde ciddi biçimde upstreaming yapıyor
      Son dönemde ilerlemenin yavaşlamasının büyük nedeni de diff sayısını azaltmaya odaklanmalarıydı ve epey fazla çalışma zaten mainline kernel'e girmiş durumda
      Asahi ayrıca yeni özellikleri denemek için bir alan görevi görüyor
    • Ek bir zorluk da ARM Mac'lerin sürekli hareket eden bir hedef olması
      Apple'ın Asahi Linux için istikrar ya da destek sağlama gibi bir niyeti yok ve PC sektöründeki gibi uzun vadeli uyumluluğu korumak için de bir nedeni bulunmuyor; bu yüzden ileride de Asahi'yi zorlaştıracak değişiklikler yaparsa pek umursamayacak gibi görünüyor
    • Linux'un güzel tarafı özgür yazılım olması; yani hissedarlara ya da kârlılığa bağlı olmaması
      M1 MacBook Air'de Asahi'yi varsayılan işletim sistemi olarak kullanıyorum ve oldukça memnunum; uykudayken pilin saatte %1 azalması gibi eksiler olsa da sırf %100 tamamlanmış değil diye hiç olmamasındansa mevcut hali çok daha iyi
      Zaten genel kitle için kusursuz biçimde cilalanmış olmasına da çok ihtiyaç duymuyorum
    • Mainline kernel geliştirme zaten herkesin kendi fork'unda çalışıp yamaları upstream'e göndermesi şeklinde ilerliyor
      Asahi'nin özel görünmesinin nedeni tuhaf ve kendine özgü donanımının çok olması, dolayısıyla çok sayıda özel sürücü gerektirmesi; kimse doğrudan Linus'un ağacında geliştirme yapmıyor
    • 39c3'teki https://youtu.be/3OAiOfCcYFM sunumu da iyiydi
      Sonuçta hedef, Linux'un Apple Silicon'ı yerel olarak desteklemesi

  • Bu projenin ivmesini korumasını isterim
    Apple donanımı + Linux birleşimi, en iyi donanım üzerinde çalışan en az bozuk işletim sistemi gibi hissettiriyor; macOS ise hatalar ve her sürümde ters yüz olan değişiklikler yüzünden giderek daha kaotik geliyor

    • Framework üzerinde Fedora kullanırsan fikrin değişebilir
      Deneyim çok akıcıydı ve yakında çıkacak Framework 13 Pro'nun pil ve trackpad açısından da macOS seviyesinde, hatta pilde daha iyi olması bekleniyor
    • Üç büyük işletim sistemini de kullandım; macOS en az hatalı ve kutudan çıktığı haliyle en sorunsuz çalışanıydı
      Linux'ta hep ses ya da ekran uyumluluğu için garip yamalar yapmak zorunda kaldım, Windows'ta ise pil sorunları ciddiydi
      Linux ayarlarıyla uğraşmayı seven birçok insanın aslında daha fazla özelleştirilebilir bir Mac benzeri deneyim istediği de düşünülebilir
    • Genel olarak öyle, ama MLX çevresindeki ekosistem oldukça güçlü biçimde toparlandı
      Disk G/Ç kötü ve işletim sisteminde hatalar olsa bile en azından modern bir işletim sisteminde ML derlenip çalışıyor
      Buna karşılık rocm neredeyse hazırmış gibi görünüp sonra önceden derlenmiş paketler ya da iki yıldan eski Ubuntu istemesiyle can sıkıyor
      https://github.com/ROCm/TheRock/issues/3477
    • Son zamanlarda iş için MacBook Air kullandım ama donanımın birinci sınıf olduğu iddiasına katılmak zor
      5 euro harcayıp bile daha iyi bir klavye bulunabilir gibi geliyor

  • Apple'ın neden bu çabaya yardımcı olmadığını ve belge yayınlamadığını anlamakta zorlanıyorum
    Rekabet avantajı ya da gizlilik gibi klasik nedenler artık pek ikna edici görünmüyor

    • Gerçek neden daha basit olabilir
      Apple donanım marjı yüksek olduğu için Linux kullanıcılarına MacBook satarak yine kazanır, ama resmi olarak Linux desteğini kabul ettiği anda bu doğrudan bir destek yükümlülüğüne dönüşür
      Her kernel panic için Genius Bar ziyareti, her sürücü hatasında @AppleSupport çağrısı gelecektir; dolayısıyla bugünkü gibi gayriresmî kalması, Apple açısından donanım satışını alıp destek yükünü almamanın en iyi yolu olabilir
    • Mali getirisi neredeyse yok ve donanım her değiştiğinde Linux için ayrıca belgeleme yükü doğuyor
      En gürültücü ve eleştirel kullanıcı kitlesi olmalarına rağmen küçük bir topluluk olmaları da Apple açısından cazip görünmeyebilir
    • Doğrudan biz bu oyunda yokuz çizgisini çekmek, seçici açıklık ya da özel arayüzlerin uyumluluğunu bozduğu için eleştirilmekten çok daha kolay olabilir
      İçeride de önceliklerle ilgisiz tartışmaların sürekli dönmesini engeller
    • Bunun neredeyse right to repair ile bağlantılı olduğunu düşünüyorum
      Dizüstü bilgisayarlar çok sayıda donanım parçası ve bunları çalıştıran sürücülerden oluşuyor; insan da satın aldığı şeyin donanım ve sürücülerin ayrılmaz bir paketi mi, yoksa bir taraf bozulduğunda diğer tarafı kendi başına ayağa kaldırabilmek için kılavuz alması gereken bir sistem mi olduğunu sorguluyor
      Apple sürücülerin dişli ya da motor gibi aşınmadığını söyleyebilir, ama bu yine de nasıl çalıştıklarını bilme hakkını ortadan kaldırmaz
      Bir gün /System/Trackpad.kext uzaydan gelen bir cisme çarpıp yok olduğunda ve biri sürücüyü kendisi yazmak zorunda kaldığı için mahkemede belge talep ettiğinde buna şaşırmam
    • Mantıklı geliyor
      Apple'ın bunu desteklemesi kolay olurdu ve topluluktan kazanacağı iyi niyet de epey büyük olurdu

  • Mac benzeri varsayılan deneyime odaklanan bir Asahi Remix sürümü olsa ilgi görür mü merak ediyorum
    Örneğin cmd ana değiştirici tuş olur, Mac tarzı kısayollar, tema ve jestler varsayılan gelir
    Bunlar her dağıtımda elle yapılabilir ama iyi kürate edilmiş varsayılanların ayrı bir değeri var

    • cmd'yi “ana değiştirici tuş” yapmak biraz sorunlu
      Tipik X/Wayland ortamlarında masaüstü işlevleri tarafında zaten Cmd öne çıkarken, uygulama düzeyinde Ctrl öne çıkıyor; bunu değiştirince çok fazla çakışma ortaya çıkıyor
    • KDE'de buna oldukça yakın bir düzen kurmayı başardım
      Claude Code'dan bunu uygulamasını istedim, o da web'de arayıp ayar dosyalarını bile hazırladı
    • Cmd merkezli tuş dizilimi fiilen kaybedilmiş bir savaş gibi geliyor
      Defalarca denedim ama sonunda Ctrl düzenini kabullendim ve son MacBook'umu da sattım

  • MacBook Pro + Linux hayalindeki geliştirme makinesini önce donanım mı yoksa yazılım mı gerçeğe dönüştürecek, merak ediyorum
    Asahi'nin yazılım tarafında mı önce oraya ulaşacağını, yoksa Framework'ün donanım tarafında mı önce bunu başaracağını göreceğiz

  • MacBook Neo + Asahi kombinasyonu olursa gerçekten çok güçlü olabilir

  • M3 desteğinin upstream backlog'u eritip araçları iyileştirirken istikrarlı biçimde ilerlediğini görmek sevindirici
    PCIe, MacBook klavye ve trackpad'i, SMC tabanlı RTC ve reboot controller ile NVMe controller desteği için yamalar Asahi kernel ağacına giriyor; böylece M3 için Linux desteği kabaca M1 için ilk Asahi Linux alpha seviyesine yaklaşmış oluyor

    • Bu hızla giderse ancak M6 çıktığında gerçekten kullanılabilir hale gelecek olabilir

  • Bu tür proje raporlarında sürekli ilerleme sağlayan çıkış yolları görülmesi ve gerçek kullanıcıların nerelerde zorlandığının tam isabetle tespit edilmesi, Asahi ekibinin gerçekten çok tecrübeli olduğunu düşündürüyor
    Yakında Asahi'ye yeniden tamamen dönmek istiyorum

  • M3'ün alpha seviyesine yaklaşması harika bir haber ve sırada M4'ü de merakla bekliyorum
    Buna karşılık Apple'ın bu yıl ya da gelecek yıl macOS'ta neyi daha bozacağını hiç merak etmiyorum