deploy: 34287c6

Author: marcan

2024/01/fedora-asahi-new/index.html

@@ -55,7 +55,7 @@ <h1 class=entry-title>New in Fedora Asahi Remix</h1><ul class=blog-nav>
 <p>Fedora 39 Asahi Remix KDE System Information</p></p></figcaption></figure><h2 id=widevine---netflix-and-spotify-on-asahi>Widevine - Netflix and Spotify on Asahi</h2><p>What good is a desktop if Netflix and Spotify doesn&rsquo;t work? Media distribution services often require a Digial Rights Management (DRM) system to deliver protected premium content, which goes as smoothly on FOSS Linux as you&rsquo;d expect. While Apple works directly with Netflix to deploy their custom DRM solution called &ldquo;FairPlay&rdquo;, FairPlay simply does not exist on Linux, and the hardware restricts it to only unmodified macOS installs. Still, many people need their Spotify. Widevine is Google&rsquo;s proprietary &ldquo;cross-platform&rdquo; content protection solution, so simply installing the Widevine blob should make Netflix and Spotify work. Unfortunately, one does not simply &ldquo;install&rdquo; Widevine on a platform that isn&rsquo;t officially supported by Google.</p><p>Very recently, some ARM64 Linux-ish platforms with Widevine did pop into existence: some ChromeOS laptops. Unfortunately ChromeOS is only &ldquo;Linux-ish&rdquo;, and ChromeOS binaries cannot run unmodified on standard ARM64 desktop Linux. The Widevine blobs had to be manually patched to work around both memory page alignment issues and glibc incompatibilities. Despite being a horrendous hack, we&rsquo;ve been able to package it into a <a href=https://github.com/AsahiLinux/widevine-installer>reliable user-friendly installer</a> that ships preinstalled on Fedora Asahi Remix and should work on most other ARM64 distributions with a reasonably recent glibc. The whole process can be summarized in meme format, but you can also check out <a href=https://github.com/DavidBuchanan314/>David Buchanan</a>&rsquo;s original write-up <a href=https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html>here</a>. Netflix and Spotify for all.</p><figure class=captioned>
 <img src=/img/blog/2024/01/widevine.jpg alt="You wouldn't pay for 4K Netflix and then download a chromebook recovery image..." class=center width=63%>
 <figcaption>
-<p>You wouldn't pay for 4K Netflix and...</p><p><a href=https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html>Source: David Buchanan, The Quest for Netflix on Asahi Linux</a></p></figcaption></figure><h2 id=openh264---lawyers-love-this-one-h264-trick>OpenH264 - Lawyers love this one H.264 trick</h2><p>In tangentially related news, certain moving picture compression standards (e.g. H.264/H.265) are encumbered with vociferously defended patents, so Fedora cannot legally ship them. marcan takes pride in Asahi&rsquo;s seamless out-of-the-box experience, and H.264 being video people&rsquo;s JPEG or the &ldquo;fallback codec&rdquo;, out-of-the-box H.264 support was imperative. Fedora does support H.264 via OpenH264 from Cisco, which is an open source H.264 implementation that is distributed as a pre-compiled binary. Cisco Systems covers the appropriate licensing royalties, as long as the binary is downloaded and installed directly from their repository. Traditionally, this means that users have had to manually install OpenH264 after installing Fedora Linux.</p><p>Since our Asahi Linux installer happens to install directly from the Internet anyway, we added support for pre-downloading these codec packages directly from Cisco&rsquo;s servers as part of the installation process. A little script then takes care of immediately installing them on first boot, and the result is that Fedora Asahi Remix is the first Fedora spin to ship with H.264 straight out of the box, fully lawyer-approved.</p><p>Users who wish to use other patent-encumbered codecs under their own resposibility may choose to install them from third-party repositories, such as the <code>libavcodec-freeworld</code> package in <a href=https://docs.fedoraproject.org/en-US/quick-docs/rpmfusion-setup/>RPM Fusion</a>. Note that RPM Fusion is not affiliated with Fedora nor Asahi Linux.</p><h1 id=work-in-progress>Work In Progress&mldr;</h1><p>Now for some tricks we have up our sleeves. These may or may not arrive sometime in 2024.</p><h2 id=hardware-video-decode>Hardware Video Decode</h2><p>OpenH264 may decode H.264 by definition, but it cannot decode H.265/HEVC, which is basically H.264 cranked up including the licensing part. OpenH264 could also be faster: it has very little SIMD code, and even less ARM64 SIMD (Janne would know..). The release of speaker support has heightened the need for fast, high-quality, and power-efficent video decoding. While software decode on the M-series cores is faster than some hardware decoders, some users report their laptop battery converts to released heat at a noticeably faster rate than macOS. We want to at least match macOS efficiency numbers.</p><p>The Apple Video Decoder is a multiformat programmable hardware driven by a custom instruction set specialized for decoding video. AVD, despite its complexity, oddly enough lacks a firmware handling the low-level decode logic, so we have to RE literally every bit ourselves (side effect, the entire driver/firmware stack will be fully open-source). And video codec standards being 880-page manual beasts, it&rsquo;s not the easiest effort. Eileen&rsquo;s <a href=https://github.com/eiln/avd>avd repo</a> currently boasts H.264 High Profile, High 4:2:2 Profile, High 10 Profile, and High 10 4:2:2 Profile, so that beats openh264 in features alone. HEVC is nearing conformancy. A VP9 proof-of-concept exists.</p><figure class=captioned>
+<p>You wouldn't pay for 4K Netflix and...</p><p><a href=https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html>Source: David Buchanan, The Quest for Netflix on Asahi Linux</a></p></figcaption></figure><h2 id=openh264---lawyers-love-this-one-h264-trick>OpenH264 - Lawyers love this one H.264 trick</h2><p>In tangentially related news, certain moving picture compression standards (e.g. H.264/H.265) are encumbered with vociferously defended patents, so Fedora cannot legally ship them. marcan takes pride in Asahi&rsquo;s seamless out-of-the-box experience, and H.264 being video people&rsquo;s JPEG or the &ldquo;fallback codec&rdquo;, out-of-the-box H.264 support was imperative. Fedora does support H.264 via OpenH264 from Cisco, which is an open source H.264 implementation that is distributed as a pre-compiled binary. Cisco Systems covers the appropriate licensing royalties, as long as the binary is downloaded and installed directly from their repository. Traditionally, this means that users have had to manually install OpenH264 after installing Fedora Linux.</p><p>Since our Asahi Linux installer happens to install directly from the Internet anyway, we added support for pre-downloading these codec packages directly from Cisco&rsquo;s servers as part of the installation process. A little script then takes care of immediately installing them on first boot, and the result is that Fedora Asahi Remix is the first Fedora spin to ship with H.264 straight out of the box, fully lawyer-approved.</p><p>Users who wish to use other patent-encumbered codecs under their own resposibility may choose to install them from third-party repositories, such as the <code>libavcodec-freeworld</code> package in <a href=https://docs.fedoraproject.org/en-US/quick-docs/rpmfusion-setup/>RPM Fusion</a>. Note that RPM Fusion is not affiliated with Fedora nor Asahi Linux.</p><h1 id=work-in-progress>Work In Progress&mldr;</h1><p>Now for some tricks we have up our sleeves. These may or may not arrive sometime in 2024.</p><h2 id=hardware-video-decode>Hardware Video Decode</h2><p>OpenH264 may decode H.264 by definition, but it cannot decode H.265/HEVC, which is basically H.264 cranked up including the licensing part. OpenH264 could also be faster: it has very little SIMD code, and even less ARM64 SIMD (Janne would know..). The release of speaker support has heightened the need for fast, high-quality, and power-efficent video decoding. While software decode on the M-series cores is faster than some hardware decoders, some users report their laptop battery converts to released heat at a noticeably faster rate than macOS. We want to at least match macOS efficiency numbers.</p><p>The Apple Video Decoder is a multiformat programmable hardware driven by a custom instruction set specialized for decoding video. AVD, despite its complexity, oddly enough lacks a firmware handling the low-level decode logic, so we have to RE literally every bit ourselves (side effect, the entire driver/firmware stack will be fully open-source). And video codec standards being 880-page manual beasts, it&rsquo;s not the easiest effort. Eileen&rsquo;s <a href=https://github.com/eiln/avd>avd repo</a> currently boasts H.264 High Profile, High 4:2:2 Profile, High 10 Profile, and High 10 4:2:2 Profile, so that beats openh264 in features alone. HEVC is nearing conformance. A VP9 proof-of-concept exists.</p><figure class=captioned>
 <img src=/img/blog/2024/01/avd.png alt="AVD decoding VP9-encoded Matrix shootout scene over m1n1 proxy" class=center width=100%>
 <figcaption>
 <p>AVD decoding VP9-encoded Matrix shootout scene over m1n1 proxy.</p><p><a href=https://github.com/eiln/avd>Source: https://github.com/eiln/avd</a></p></figcaption></figure><p>Another hurdle is the Linux video hardware acceleration API. Current options cannot yet handle all the demands of a video decoder driver that lacks a firmware handling a signifcant chunk of the decoding logic. V4L2? VA-API? Vulkan? To be answered in 2024.</p><h2 id=can-we-run-steam>&ldquo;Can we run Steam?&rdquo;</h2><p>Apple Silicon devices use 16K pages, but the rest of the (x86) world runs on 4K. Running Apple Silicon on a 4K kernel is technically feasible, but it requires a number of invasive and controversial upstream changes and comes with a significant impact on performance. A better approach would be running the host with the native 16K kernel, and using a 4K kernel in a VM for those problematic workloads, assuming the performance of the VM is good enough for the use case.</p><p>But 3D performance in VMs is not so good. Or is it? At <a href="https://www.youtube.com/watch?v=9sFP_yddLLQ">XDC 2022</a>, Rob Clark demonstrated that, with a technique called &ldquo;DRM native context&rdquo;, it is possible to achieve near-native performance for 3D acceleration in a VM. Now the question is whether we can port DRM native context to Asahi Linux, given that it needs to be individually implemented for each DRM driver. This is a quite significant project and involves changes in multiple components. We need to implement the equivalent of Rob Clark&rsquo;s work on freedreno for the asahi/agx drivers both in Mesa and virglrenderer. We also need to extend libkrun (a lightweight VMM used to start and drive the VM) to support virtio-gpu+rutabaga, along with virtio-snd support, as audio tends to be quite an important feature for gaming ;-)</p><figure class=captioned>