Asahi Linux प्रगति रिपोर्ट Linux 7.0

 (asahilinux.org)
1 पॉइंट द्वारा GN⁺ 3 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple Silicon के लिए Linux support में installer automation, power management, audio, display, और M3 enablement तक कई मोर्चों पर एक साथ प्रगति हुई है
  • Asahi Installer में image manifest को codebase से अलग किया गया है और GitHub workflow deployment जोड़ा गया है, जिससे इसे अब अधिक बार अपडेट किया जा सके; 0.8.0 में m1n1 stage 1 अपडेट, Mac Pro install support, और firmware update mode जोड़ा गया है
  • ALS calibration firmware अब macOS से निकालकर install के बाद भी दोबारा अपडेट किया जा सकता है, Bluetooth audio stutter Broadcom coexistence command support से खत्म हो गया है, और PMP support से M1 Pro पर idle power लगभग 0.5W कम हुई है
  • VRR support अभी Apple DCP constraints की वजह से userspace में सही तरह expose नहीं हो पा रहा, लेकिन pull request merge होने पर इसे kernel module parameter से force enable किया जा सकेगा; audio stack के upstream काम में bus keeper के लिए generic API और CS42L84 के लिए अतिरिक्त sample rate support भी शामिल हुआ है
  • M3 support coverage अब PCIe, input devices, RTC, reboot controller, और NVMe तक बढ़ गई है, और Fedora Asahi Remix 44 नया Plasma-आधारित install flow लेकर Fedora 44 के समय के साथ रिलीज़ बनाए रखेगा

installer automation और firmware update

  • लगभग 2 साल तक बहुत कम अपडेट पाने वाला Asahi Installer manual release प्रक्रिया और CDN admin privileges पर निर्भरता के कारण लंबे update cycle में फंसा रहा, और जून 2024 tag के बाद से बदलाव भी काफी जमा हो गए थे
  • UEFI-only install में सिर्फ m1n1 stage 1, Devicetree, और U-Boot install किए जाते हैं, इसलिए अगर installer bundle में मौजूद Devicetree kernel की अपेक्षाओं से मेल न खाए तो boot ही रुक सकता है
    • upstream के दौरान Devicetree bindings बदलते रहे, जिससे mismatch जमा होता गया, और kernel 6.18 में Apple USB से जुड़े बदलाव बढ़ने के कारण live media से 6.18 या उससे ऊपर boot करना संभव नहीं रहा
  • installable image manifest को asahi-installer-data में अलग किया गया है, ताकि इसे installer codebase से स्वतंत्र रूप से अपडेट किया जा सके
  • asahi-installer का deployment अब GitHub workflow से automate कर दिया गया है
    • main branch पर push होने पर https://alx.sh/dev पर build और upload अपने-आप होता है
    • GitHub tag push होने पर https://alx.sh पर automatic deployment होता है
  • नया 0.8.0 bundled m1n1 stage 1 को 1.5.2 तक लाता है, और Mac Pro install support के साथ firmware update mode भी जोड़ता है

ALS और firmware extraction

  • Apple के True Tone environment में सिर्फ ambient brightness ही नहीं बल्कि lighting के color characteristics भी मापने पड़ते हैं, इसलिए ALS data processing और calibration accuracy महत्वपूर्ण हो जाती है
  • AOP और ALS driver पहले से काम कर रहे थे, लेकिन calibration data के बिना AOP द्वारा दिया गया ALS raw data पर्याप्त सटीक नहीं होता
    • यह calibration data एक binary blob है जिसे runtime में AOP पर अपलोड करना पड़ता है, और इसे redistribute नहीं किया जा सकता, इसलिए install के समय इसे macOS से लाना पड़ता है
  • Asahi Installer Linux के लिए ज़रूरी firmware को इकट्ठा करके EFI System Partition में रखता है, और Dracut module इसे /lib/firmware/ के नीचे subdirectory के रूप में mount करता है ताकि driver इसे ढूंढ सकें
  • install हो जाने के बाद अतिरिक्त firmware की ज़रूरत पड़ने वाली समस्या को रोकने के लिए installer अब vendor firmware package के automatic update को support करता है
    • ALS से शुरू करते हुए, अब macOS या macOS Recovery में boot करके installer दोबारा चलाने और prompt follow करने पर ज़रूरी firmware अपडेट किया जा सकता है
  • ALS support और बाद के firmware upgrade के लिए Asahi kernel 6.19 या उससे नया और iio-sensor-proxy चाहिए

power management और PMP

  • idle power consumption खासकर Pro/Max/Ultra SoC पर लगातार समस्या रही है, और इस platform का power management PMGR और PMP के साथ जुड़ी एक जटिल संरचना रखता है
  • PMGR SoC power domains को on/off करता है, जबकि PMP shared memory के जरिए SoC blocks और application cores से आने वाली power state reports को पढ़कर process करता है
    • अगर PMP boot न हो तो वह इन reports को पढ़ नहीं पाता, और कुछ power management features भी काम नहीं करते
  • chaos_princess द्वारा बनाया गया PMP support driver SoC blocks और PMGR reports को PMP तक पहुंचाता है, और 14-inch M1 Pro MacBook Pro के idle state में लगभग 0.5W की बचत हासिल करता है
    • यह idle power में लगभग 20% कमी के बराबर है
  • macOS जैसी idle और sleep timing तक पहुंचने के लिए अभी और काम बाकी है, लेकिन यह बदलाव एक बड़ी प्रगति है
  • base M1 बाद की पीढ़ियों से incompatible पुराना PMP variant इस्तेमाल करता है, और dd-dreams उस support पर काम कर रहे हैं
  • PMP अभी सभी supported devices पर verify नहीं हुआ है, और upstream merge से पहले इसे default enable करने की योजना नहीं है
    • जो उपयोगकर्ता Devicetree बदल सकते हैं, वे device DTS में APPLE_USE_PMP define करके इसे enable कर सकते हैं

Bluetooth audio dropouts का समाधान

  • Bluetooth और WiFi एक ही 2.4GHz band साझा करते हैं, इसलिए interference होना आसान है, और audio stream जैसी latency तथा continuity-संवेदनशील connections को ज्यादा priority चाहिए होती है
  • Broadcom की coexistence setting Bluetooth HCI के vendor-specific extension commands से संभाली जाती है, लेकिन upstream Linux kernel इन्हें support नहीं करता था, जिससे Bluetooth scan के दौरान audio packet loss हो जाता था
    • अगर KDE Connect Bluetooth scan trigger करता था, तो audio drop हो सकता था
  • chaos_princess ने kernel Bluetooth stack में इस command support को जोड़ा, और BlueZ सभी audio streams को high priority के रूप में mark करता है, इसलिए streaming के दौरान ज़रूरी command अपने-आप trigger हो जाती है
  • इसका नतीजा यह है कि Bluetooth audio dropout अब नहीं होता

DCP और VRR

  • DCP firmware interface बहुत बड़ा है और version-दर-version अस्थिर रहता है, और अब तक basic display support के बाद दूसरे hardware कार्यों को प्राथमिकता मिलने से VRR जैसी सुविधाएं पीछे रह गई थीं
  • VRR support के लिए display controller और display के बीच special packet exchange, frame display timing के अनुसार vertical blanking adjustment, display की VRR capability advertisement, और KMS integration — सबकी ज़रूरत होती है
  • tracing के दौरान पता चला कि external display को power देने पर 0 पर सेट किया जाने वाला DCP parameter, VRR on/off के समय 0x300000 और 0x0 के बीच बदलता है
    • test display की minimum refresh rate 48Hz थी, और DCP fixed-point format में 48 का मान 0x300000 था
    • यह parameter power sequencing के लिए नहीं बल्कि VRR minimum refresh rate toggle था, और modeset से पहले 0 डालने पर VRR disable हो जाता था
  • MacBook Pro की ProMotion internal display भी इसी तरह enable होती है, लेकिन internal panel EDID/DisplayID advertise नहीं करता, इसलिए Linux driver को यह पहचानना पड़ता है कि यह internal LCD है और ज़रूरी properties को statically set करना पड़ता है
  • VESA DisplayPort Adaptive Sync और KMS API, VRR state transition के दौरान modeset requirement की अनुमति नहीं देते, लेकिन Apple DCP इस सीमा से नहीं बच पाता
    • इसी constraint की वजह से VRR को userspace में सही ढंग से expose नहीं किया जा सकता, और KWin भी ऐसे interface को ignore कर देता है
  • अभी pull request merge होने पर appledrm.force_vrr kernel module parameter के जरिए force VRR enable किया जा सकेगा
    • अगर display VRR support करता है, तो DCP KMS या compositor को बताए बिना VRR का उपयोग करेगा
    • KWin में यह अच्छी तरह काम कर रहा था, लेकिन दूसरे compositor में अनुभव अलग हो सकता है
  • HDMI पक्ष में VRR transitions के बीच modeset पर रोक नहीं है, और Intel जैसे दूसरे display controllers भी इसी तरह काम करते हैं
    • upstream में VRR mode को हमेशा on रखने या transition के दौरान modeset allow करने जैसे विकल्पों पर चर्चा चल रही है, और दिशा तय होने पर VRR को अपेक्षित तरीके से expose करने की योजना है

audio stack upstream और sample rate विस्तार

  • पूरे audio stack का upstream काम जारी है, और Cirrus Logic तथा Texas Instruments से जुड़े headphone jack, speaker amp drivers, I2S peripherals, और Apple DMA controller बदलाव पहले ही merge हो चुके हैं
  • इस platform पर speaker protection का ढांचा ऐसा है कि TI amp I2S के जरिए voltage और current को SoC तक भेजता है, और speaker के Thiele/Small Parameters के साथ voice coil temperature की गणना की जाती है
    • macOS में यह काम CoreAudio करता है, जबकि Linux में speakersafetyd इसे संभालता है
  • कई amps के data transmit pins serial में जुड़े होने और left/right lines के OR-combined होने वाली संरचना में, जब एक side transmit करे तो दूसरी side को logic low सुनिश्चित करना पड़ता है, इसलिए bus keeper setting की ज़रूरत होती है
  • पहले bus keeper को amp chip driver और dedicated Devicetree binding से संभाला जाता था, लेकिन upstream के लिए यह बहुत सीमित था, इसलिए इसे generic API में बदला गया
    • अब कोई भी configurable ASoC component bus keeper की मौजूदगी expose कर सकता है, और platform driver runtime पर ज़रूरी setting लागू कर सकता है
    • यह patchset Linux 7.1 में merge हो गया है
  • Apple-specific variant chips का support भी लगातार बढ़ रहा है
    • TI speaker amps के लिए TAS2764 और TAS2770 upstream drivers में अपेक्षाकृत आसानी से Apple variants का support जोड़ा गया
    • CS42L84, CS42L42 से काफी अलग है, इसलिए इसके लिए अलग Linux driver की ज़रूरत पड़ी, और वह पहले ही upstream में शामिल हो चुका है
  • अगर सिर्फ macOS tracing को आधार बनाया जाए, तो सिर्फ macOS द्वारा इस्तेमाल की जाने वाली सुविधाएं ही expose होती हैं; इसी कारण शुरू में CS42L84 पर केवल 48kHz और 96kHz support जोड़ा गया था
    • यह सीमा PipeWire को दूसरे streams को resample करने पर मजबूर करती थी, जिससे CPU और battery अधिक खर्च होते थे और sound quality भी घटती थी
  • CS42L42 datasheet में दिए गए दूसरे common sample rates को CS42L84 driver पर लागू करने के बाद, headphone jack input और output दोनों पर 44.1, 88.2, 176.4, 192kHz hardware support काम करने लगा
    • यह patch upstream में submit किया गया, Linux 7.1 में merge हुआ, और Asahi kernel 6.19.9 में backport भी किया गया

M3 support का विस्तार

  • Asahi kernel tree में M3 devices के लिए अतिरिक्त hardware enablement patches भी जोड़े जा रहे हैं
  • इसमें PCIe, MacBook keyboard और trackpad, SMC-based RTC और reboot controller, तथा NVMe controller तक support बढ़ा है
  • Michael Reeves और Alyssa Milburn के काम से M3 पर Linux support का स्तर पहले Asahi Linux alpha for M1 के लगभग समान चरण तक पहुंच गया है
  • Asahi Installer के जरिए M3 install को तुरंत खोलने की तैयारी अभी पूरी नहीं हुई है, लेकिन काम जारी है

Fedora Asahi Remix 44

  • Fedora Asahi Remix 43 में देरी के बावजूद, Fedora Asahi Remix 44 की योजना 28 अप्रैल को Fedora Linux 44 के साथ या उसके कुछ दिनों के भीतर रिलीज़ बनाए रखने की है
  • नया KDE Plasma-आधारित install, Plasma 6.6 की नई सुविधाओं का उपयोग करेगा
    • Plasma Setup पुराने Calamares-आधारित setup wizard की जगह लेगा और Plasma-native account creation तथा system setup flow देगा
    • Plasma Login Manager default greeter और session manager बनेगा, और SDDM की जगह लेगा
  • यह बदलाव सिर्फ नई installations पर लागू होगा; पुराने Fedora Asahi Remix से upgrade करने वाले उपयोगकर्ताओं की settings नहीं बदलेंगी
  • Fedora Asahi Remix 44, vendored Mesa और virglrenderer packages को समाप्त कर रहा है
    • जिन उपयोगकर्ताओं ने अभी तक manual switch नहीं किया है, वे upstream Fedora repository के Mesa और virglrenderer packages पर अपने-आप migrate हो जाएंगे

प्रायोजन और infrastructure support

  • सहयोग OpenCollective और GitHub Sponsors पर जारी है
  • Bunny परियोजना की शुरुआत से मुफ्त CDN और hosting services उपलब्ध करा रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 일 전
Hacker News की राय

  • CS42L84 को macOS में केवल 48/96 kHz उपयोग करने के लिए सेट किया गया था, लेकिन CS42L42 datasheet से दूसरे sample rate मान लेकर driver में डालने पर वह वैसे ही काम करता दिखा
    headphone jack input/output में 44.1/88.2/176.4/192 kHz support देने वाला patch upstream में चला गया, 7.1 में merge हो गया, और Asahi kernel 6.19.9 में backport भी कर दिया गया ताकि इसे तुरंत इस्तेमाल किया जा सके
    chip tracing और reverse engineering वाकई प्रभावशाली है

    • सबसे हैरान करने वाली बात यह है कि अगर केवल 48/96 kHz support हो, तो PipeWire resampling की वजह से CPU और battery ज़्यादा इस्तेमाल करता है
      Apple power efficiency को लेकर इतनी जुनूनी कंपनी है, फिर भी यह अभी तक ऐसा क्यों रखे हुए है, यह सोचने वाली बात है
    • 44.1 kHz bit-perfect CD/FLAC playback संभव हो जाना सच में एक बड़ा feature लगता है

  • Asahi टीम की तकनीकी पोस्ट और उपलब्धियाँ सच में शानदार हैं, लेकिन यह बात थोड़ी चिंता देती है कि यह अभी भी एक अलग project बना हुआ है, और kernel mainline या Ubuntu, Debian, Fedora जैसी मुख्यधारा distributions के भीतर टिके रहने वाले रूप में नहीं है
    reverse engineering projects 80% तक उपयोगी नतीजे अपेक्षाकृत आसानी से दे सकते हैं, लेकिन आम users के लिए पर्याप्त रूप से polished 95% completeness तक पहुँचने के लिए लगभग उतने ही स्तर का और मेहनती, बारीक काम और चाहिए होता है

    • Asahi भी उसी दिशा में काफी upstreaming कर रहा है
      हाल की प्रगति धीमी दिखने की एक बड़ी वजह यह भी है कि वह diff की संख्या घटाने पर फोकस कर रहा था, और काफी काम पहले ही mainline kernel में जा चुका है
      Asahi नए features को experiment करने की जगह भी है
    • एक अतिरिक्त मुश्किल यह भी है कि ARM Mac खुद लगातार बदलता हुआ target है
      Apple का Asahi Linux के लिए stability या support देने का कोई इरादा नहीं दिखता, और PC industry की तरह लंबे समय की compatibility बनाए रखने की भी उसे कोई ज़रूरत नहीं है, इसलिए आगे भी Asahi के लिए मुश्किल पैदा करने वाले बदलाव करे तो शायद उसे फर्क नहीं पड़ेगा
    • Linux की अच्छी बात यह है कि यह free software है, इसलिए यह shareholders या profitability की बाधाओं में नहीं बँधा
      मैं M1 MacBook Air पर Asahi को default OS की तरह इस्तेमाल कर रहा हूँ और काफी संतुष्ट हूँ; sleep के दौरान battery का हर घंटे 1% गिरना जैसी कमियाँ हैं, फिर भी 100% feature complete न होने की वजह से उसके बिल्कुल न होने से यह मौजूदा रूप कहीं बेहतर है
      यह ज़रूरी भी नहीं लगता कि इसे आम जनता के लिए पूरी तरह polished होना ही चाहिए
    • mainline kernel development मूल रूप से ऐसा ही होता है कि सब लोग अपने fork में काम करते हैं और फिर patch upstream भेजते हैं
      Asahi बस इसलिए अलग दिखता है क्योंकि इसमें बहुत सा अजीब और dedicated hardware है, इसलिए कई special drivers चाहिए; कोई भी सीधे Linus की tree में development नहीं करता
    • 39c3 का https://youtu.be/3OAiOfCcYFM presentation भी अच्छा था
      आखिरकार लक्ष्य Linux को Apple Silicon का native support दिलाना ही है

  • उम्मीद है कि इस project की रफ़्तार बनी रहे
    Apple hardware + Linux का संयोजन सबसे अच्छे hardware पर चलने वाला सबसे कम टूटा हुआ OS लगता है, जबकि macOS bugs और हर version में उलट-पुलट बदलावों की वजह से और उलझा हुआ महसूस होता है

    • अगर Framework पर Fedora चलाकर देखें तो शायद राय बदल जाए
      अनुभव बहुत smooth था, और आने वाला Framework 13 Pro battery और trackpad के मामले में macOS जितना, या battery में शायद उससे भी बेहतर हो सकता है, ऐसी उम्मीद है
    • तीनों बड़े OS इस्तेमाल किए हैं, और macOS में सबसे कम bugs थे और वह बस ठीक से चलता था
      Linux में हमेशा audio या display compatibility के लिए अजीब patches लगाने पड़े, और Windows में battery की समस्या गंभीर थी
      Linux tuning पसंद करने वाले कई लोग अंत में शायद ज़्यादा customization वाला Mac जैसा experience ही चाहते दिखते हैं
    • कुल मिलाकर ऐसा है, लेकिन MLX के आसपास का ecosystem काफ़ी मज़बूती से बना हुआ है
      disk I/O खास नहीं है और OS में bugs भी हैं, फिर भी कम से कम नए OS पर ML compile होकर चल तो जाता है
      दूसरी तरफ rocm लगभग तैयार-सा लगते हुए भी prebuilt packages या 2 साल पुराने Ubuntu की ज़रूरत के कारण निराश करता है
      https://github.com/ROCm/TheRock/issues/3477
    • हाल ही में काम के लिए MacBook Air इस्तेमाल किया, लेकिन इसे top-tier hardware कहना मेरे लिए मुश्किल है
      शायद 5 यूरो खर्च करके भी इससे बेहतर keyboard मिल जाए

  • यह समझना मुश्किल है कि Apple इस कोशिश में सहयोग क्यों नहीं करता और documentation जारी क्यों नहीं करता
    competitive edge या secrecy जैसी पारंपरिक वजहें अब ज़्यादा विश्वसनीय नहीं लगतीं

    • असली वजह शायद इससे भी सरल हो सकती है
      Apple के hardware margins ऊँचे हैं, इसलिए केवल Linux users को MacBook बेच देने से भी उसे फायदा है, लेकिन जिस क्षण वह आधिकारिक Linux support को मान्यता देगा, उसी क्षण वह support responsibility बन जाएगी
      हर kernel panic पर Genius Bar की visit होगी और हर driver bug पर @AppleSupport को टैग किया जाएगा, इसलिए Apple के नज़रिए से मौजूदा unofficial स्थिति शायद सबसे अच्छा परिदृश्य है: hardware sales मिलें, support burden न आए
    • आर्थिक फायदा लगभग नहीं है, और हर बार hardware बदलने पर Linux के लिए documentation का बोझ भी उठाना पड़ेगा
      यह भी Apple को आकर्षक नहीं लगेगा कि यह users का छोटा लेकिन सबसे शोरगुल वाला और आलोचनात्मक समूह है
    • साफ़-साफ़ हम यह खेल नहीं खेलते कह देना, selective openness या private interface compatibility तोड़ने के लिए आलोचना झेलने से कहीं आसान हो सकता है
      अंदरूनी तौर पर भी इससे उन चर्चाओं से बचा जा सकता है जिनका priorities से कोई लेना-देना नहीं
    • यह बात लगभग right to repair से जुड़ी हुई लगती है
      laptop कई hardware components और उन्हें चलाने वाले drivers से मिलकर बना होता है, तो सवाल उठता है कि जो मैंने खरीदा है वह hardware और driver का अविभाज्य package है, या फिर अगर एक हिस्सा टूट जाए तो दूसरे हिस्से को खुद बचाने के लिए मुझे manual मिलना चाहिए
      Apple यह कह सकता है that drivers gears या motors की तरह घिसते नहीं, लेकिन इससे यह अधिकार खत्म नहीं हो जाता कि लोग जान सकें कि चीज़ काम कैसे करती है
      अगर कभी /System/Trackpad.kext किसी अंतरिक्षयान से टकराकर उड़ जाए और किसी को खुद driver लिखना पड़े, और वह अदालत में documentation माँगे, तो ऐसा test case भी असंभव नहीं लगेगा
    • यह बात सही लगती है
      Apple के लिए इसे support करना आसान होना चाहिए, और community से मिलने वाली goodwill भी काफ़ी हो सकती है

  • अगर Asahi Remix का ऐसा spin हो जो Mac जैसी default experience पर फोकस करे, तो क्या उसमें रुचि होगी?
    जैसे cmd को मुख्य modifier key बनाना, और Mac-style shortcuts, theme, और gestures को default रखना
    किसी भी distribution को tweak करके यह किया जा सकता है, लेकिन अच्छी तरह curated defaults की अपनी अलग value होती है

    • cmd को “मुख्य modifier key” बनाना थोड़ा मुश्किल है
      सामान्य X/Wayland environments में DE functions पहले से ही Cmd-केंद्रित होते हैं, जबकि app स्तर पर Ctrl केंद्र में रहता है; उसे बदलने पर overlap बहुत आ जाएगा
    • KDE में इसे काफ़ी हद तक वैसा बनाने में सफलता मिली
      Claude Code से इसे implement करने को कहा, तो उसने web search करके config files तक बना दीं
    • Cmd-केंद्रित keymap को मैं लगभग हारी हुई लड़ाई मानता हूँ
      कई बार कोशिश की, लेकिन अंत में Ctrl वाली ज़िंदगी स्वीकार कर ली और आख़िरी MacBook भी बेच दिया

  • यह देखना दिलचस्प होगा कि MacBook Pro + Linux वाली dream development machine को पहले hardware साकार करेगा या software
    Asahi software की तरफ़ से पहले वहाँ पहुँचता है या Framework hardware की तरफ़ से, यह देखना होगा

  • MacBook Neo + Asahi का संयोजन आए तो वह सच में बहुत ताकतवर होगा

  • यह देखना अच्छा लग रहा है कि M3 support upstream backlog साफ़ करने और tooling बेहतर बनाने के साथ लगातार आगे बढ़ रहा है
    PCIe, MacBook keyboard और trackpad, SMC-आधारित RTC और reboot controller, और NVMe controller support patches Asahi kernel tree में जा रहे हैं, और इससे M3 के Linux support का स्तर लगभग M1 के लिए पहले Asahi Linux alpha जैसा हो गया है

    • इस रफ़्तार से तो शायद M6 launch के आसपास जाकर ही यह ढंग से उपयोगी बने

  • ऐसे project reports में लगातार breakthroughs दिखना, और वास्तविक users को कहाँ दिक्कत हो रही है यह ठीक-ठीक पकड़ लेना, इस बात का संकेत है कि Asahi टीम वाकई बहुत अनुभवी है
    जल्द ही फिर से पूरी तरह Asahi पर लौटने का मन हो रहा है

  • M3 alpha के क़रीब पहुँचने की खबर वाकई शानदार है, और आगे M4 से भी उम्मीद है
    दूसरी तरफ Apple इस साल या अगले साल macOS में क्या नया बवाल करेगा, इससे कोई उम्मीद नहीं है