HTTP/2 200 server: GitHub.com content-type: application/xml last-modified: Mon, 03 Nov 2025 21:32:39 GMT access-control-allow-origin: * etag: W/"69091f77-1afb8" expires: Mon, 29 Dec 2025 21:56:24 GMT cache-control: max-age=600 content-encoding: gzip x-proxy-cache: MISS x-github-request-id: A2B7:2680BD:950572:A7422D:6952F6B0 accept-ranges: bytes age: 0 date: Mon, 29 Dec 2025 21:46:25 GMT via: 1.1 varnish x-served-by: cache-bom-vanm7210060-BOM x-cache: MISS x-cache-hits: 0 x-timer: S1767044785.803560,VS0,VE214 vary: Accept-Encoding x-fastly-request-id: d2d6dbfcc3643a9d4151d18ecff56cb669d60d6a content-length: 29201 Sofware and Development https://melissawen.github.io/ 2025-11-03 Mon, 03 Nov 2025 21:32:13 +0000 <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/1cf7853f079996cfac5bf71d53809e24a42a4083/img/kr-2025/melissa2-scaled.jpg" alt="Franks drawing of Melissa Wen with Kernel Recipes mascots around" width="200" style="float: right; margin: 20px" /></p> <p>This was the first year I attended <a href="https://kernel-recipes.org/en/2025/">Kernel Recipes</a> and I have nothing but say how much I enjoyed it and how grateful I’m for the opportunity to talk more about <a href="https://kworkflow.org/">kworkflow</a> to very experienced kernel developers. What I mostly like about Kernel Recipes is its intimate format, with only one track and many moments to get closer to experts and people that you commonly talk online during your whole year.</p> <p>In the beginning of this year, I gave the talk <a href="https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5733-don-t-let-your-motivation-go-save-time-with-kworkflow/"><strong>Don’t let your motivation go, save time with kworkflow</strong> at FOSDEM</a>, introducing kworkflow to a more diversified audience, with different levels of involvement in the Linux kernel development.</p> <p>At this year’s Kernel Recipes I presented <a href="https://kernel-recipes.org/en/2025/schedule/kworkflow-mix-match-kernel-recipes-end-to-end/">the second talk of the first day: <strong>Kworkflow - mix &amp; match kernel recipes end-to-end</strong></a>.</p> <p>The Kernel Recipes audience is a bit different from FOSDEM, with mostly long-term kernel developers, so I decided to just go directly to the point. I showed kworkflow being part of the daily life of a typical kernel developer from the local setup to install a custom kernel in different target machines to the point of sending and applying patches to/from the mailing list. In short, I showed how to mix and match kernel workflow recipes end-to-end.</p> <p>As I was a bit fast when showing some features during my presentation, in this blog post I explain each slide from my speaker notes. You can see a summary of this presentation in <a href="https://kernel-recipes.org/en/2025/live-blog-day-1-morning/">the Kernel Recipe Live Blog Day 1: morning</a>.</p> <hr /> <h2 id="introduction">Introduction</h2> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0001.png" alt="First slide: Kworkflow by Melissa Wen" /></p> <p>Hi, I’m Melissa Wen from Igalia. As we already started sharing kernel recipes and even more is coming in the next three days, in this presentation I’ll talk about kworkflow: a cookbook to mix &amp; match kernel recipes end-to-end.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0002.png" alt="Second slide: About Melissa Wen, the speaker of this talk" /></p> <p>This is my first time attending Kernel Recipes, so lemme introduce myself briefly.</p> <ul> <li>As I said, I work for Igalia, I work mostly on kernel GPU drivers in the DRM subsystem.</li> <li>In the past, I co-maintained VKMS and the v3d driver. Nowadays I focus on the AMD display driver, mostly for the Steam Deck.</li> <li>Besides code, I contribute to the Linux kernel by mentoring several newcomers in Outreachy, Google Summer of Code and Igalia Coding Experience. Also, by documenting and tooling the kernel.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0003.png" alt="Slide 3: and what's this cookbook called Kwokflow? - with kworkflow logo and KR penguin" /></p> <p>And what’s this cookbook called kworkflow?</p> <h3 id="kworkflow-kw">Kworkflow (kw)</h3> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0004.png" alt="Slide 4: text below" /></p> <p>Kworkflow is a tool created by <a href="https://siqueira.tech/">Rodrigo Siqueira</a>, my colleague at Igalia. It’s a single platform that combines software and tools to:</p> <ul> <li>optimize your kernel development workflow;</li> <li>reduce time spent in repetitive tasks;</li> <li>standardize best practices;</li> <li>ensure that deployment data flows smoothly and reliably between different kernel workflows;</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0005.png" alt="Slide 5: kworkflow is mostly a voluntary work" /></p> <p>It’s mostly done by volunteers, kernel developers using their spare time. Its features cover real use cases according to kernel developer needs.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0006.png" alt="Slide 6: Mix &amp; Match the daily life of a kernel developer" /></p> <p>Basically it’s mixing and matching the daily life of a typical kernel developer with kernel workflow recipes with some secret sauces.</p> <h2 id="first-recipe-a-good-gpu-driver-for-my-amd-laptop">First recipe: A good GPU driver for my AMD laptop</h2> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0007.png" alt="Slide 7: Let's prepare our first recipe" /></p> <p>So, it’s time to start the first recipe: A good GPU driver for my AMD laptop.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0008.png" alt="Slide 8: Ingredients and Tools" /></p> <p>Before starting any recipe we need to check the necessary ingredients and tools. So, let’s check what you have at home.</p> <p>With kworkflow, you can use:</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0009.png" alt="Slide 9: kw device and kw remote" /></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/4233667d92c15400d626da47610d701baafe72ca/img/kr-2025/gifs/laptop_kw_remote_kw_device.gif" alt="" /></p> <ul> <li> <p><code class="language-plaintext highlighter-rouge">kw device</code>: to get information about the target machine, such as: CPU model, kernel version, distribution, GPU model,</p> </li> <li> <p><code class="language-plaintext highlighter-rouge">kw remote</code>: to set the address of this machine for remote access</p> </li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0011.png" alt="Slide 11: kw config" /></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/4233667d92c15400d626da47610d701baafe72ca/img/kr-2025/gifs/laptop_kw_config.gif" alt="" /></p> <ul> <li><code class="language-plaintext highlighter-rouge">kw config</code>: you can configure kw with kw config. With this command you can basically select the tools, flags and preferences that kw will use to build and deploy a custom kernel in a target machine. You can also define recipients of your patches when sending it using kw send-patch. I’ll explain more about each feature later in this presentation.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0013.png" alt="Slide 13: kw kernel-config-manager" /></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/4233667d92c15400d626da47610d701baafe72ca/img/kr-2025/gifs/laptop_kw_k_manage.gif" alt="" /></p> <ul> <li><code class="language-plaintext highlighter-rouge">kw kernel-config manager</code> (or just <code class="language-plaintext highlighter-rouge">kw k</code>): to fetch the kernel .config file from a given machine, store multiple .config files, list and retrieve them according to your needs.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0015.png" alt="Slide 15: Preparation" /></p> <p>Now, with all ingredients and tools selected and well portioned, follow the right steps to prepare your custom kernel!</p> <p><strong>First step:</strong> Mix ingredients with <code class="language-plaintext highlighter-rouge">kw build</code> or just <code class="language-plaintext highlighter-rouge">kw b</code></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0016.png" alt="Slide 16: kw build" /></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/4233667d92c15400d626da47610d701baafe72ca/img/kr-2025/gifs/laptop_kw_build.gif" alt="" /></p> <ul> <li><code class="language-plaintext highlighter-rouge">kw b</code> and its options wrap many routines of compiling a custom kernel. <ul> <li>You can run <code class="language-plaintext highlighter-rouge">kw b -i</code> to check the name and kernel version and the number of modules that will be compiled and <code class="language-plaintext highlighter-rouge">kw b --menu</code> to change kernel configurations.</li> <li>You can also pre-configure compiling preferences in kw config regarding kernel building. For example, target architecture, the name of the generated kernel image, if you need to cross-compile this kernel for a different system and which tool to use for it, setting different warning levels, compiling with CFlags, etc.</li> <li>Then you can just run <code class="language-plaintext highlighter-rouge">kw b</code> to compile the custom kernel for a target machine.</li> </ul> </li> </ul> <p><strong>Second step:</strong> Bake it with <code class="language-plaintext highlighter-rouge">kw deploy</code> or just <code class="language-plaintext highlighter-rouge">kw d</code></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0018.png" alt="Slide 18: kw deploy" /></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/4233667d92c15400d626da47610d701baafe72ca/img/kr-2025/gifs/laptop_kw_deploy.gif" alt="" /></p> <p>After compiling the custom kernel, we want to install it in the target machine. Check the name of the custom kernel built: <code class="language-plaintext highlighter-rouge">6.17.0-rc6</code> and with <code class="language-plaintext highlighter-rouge">kw s</code> SSH access the target machine and see it’s running the kernel from the Debian distribution <code class="language-plaintext highlighter-rouge">6.16.7+deb14-amd64</code>.</p> <p>As with building settings, you can also pre-configure some deployment settings, such as compression type, path to device tree binaries, target machine (remote, local, vm), if you want to reboot the target machine just after deploying your custom kernel, and if you want to boot in the custom kernel when restarting the system after deployment.</p> <p>If you didn’t pre-configured some options, you can still customize as a command option, for example: <code class="language-plaintext highlighter-rouge">kw d --reboot</code> will reboot the system after deployment, even if I didn’t set this in my preference.</p> <p>With just running <code class="language-plaintext highlighter-rouge">kw d --reboot</code> I have installed the kernel in a given target machine and rebooted it. So when accessing the system again I can see it was booted in my custom kernel.</p> <p><strong>Third step:</strong> Time to taste with kw debug</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0020.png" alt="Slide 20: kw debug" /></p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/4233667d92c15400d626da47610d701baafe72ca/img/kr-2025/gifs/laptop_kw_remote_kw_debug.gif" alt="" /></p> <ul> <li><code class="language-plaintext highlighter-rouge">kw debug</code> wraps many tools for validating a kernel in a target machine. We can log basic dmesg info but also tracking events and ftrace. <ul> <li>With <code class="language-plaintext highlighter-rouge">kw debug --dmesg --history</code> we can grab the full dmesg log from a remote machine, if you use the <code class="language-plaintext highlighter-rouge">--follow</code> option, you will monitor dmesg outputs. You can also run a command with <code class="language-plaintext highlighter-rouge">kw debug --dmesg --cmd="&lt;my command&gt;"</code> and just collect the dmesg output related to this specific execution period.</li> <li>In the example, I’ll just unload the amdgpu driver. I use <code class="language-plaintext highlighter-rouge">kw drm --gui-off</code> to drop the graphical interface and release the amdgpu for unloading it. So I run <code class="language-plaintext highlighter-rouge">kw debug --dmesg --cmd="modprobe -r amdgpu"</code> to unload the amdgpu driver, but it fails and I couldn’t unload it.</li> </ul> </li> </ul> <h4 id="cooking-problems">Cooking Problems</h4> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0022.png" alt="Slide 22: kw patch-hub" /></p> <p>Oh no! That custom kernel isn’t tasting good. Don’t worry, as in many recipes preparations, we can search on the internet to find suggestions on how to make it tasteful, alternative ingredients and other flavours according to your taste.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/gifs/laptop_pathub.gif" alt="" /></p> <p>With <code class="language-plaintext highlighter-rouge">kw patch-hub</code> you can search on the lore kernel mailing list for possible patches that can fix your kernel issue. You can navigate in the mailing lists, check series, bookmark it if you find it relevant and apply it in your local kernel tree, creating a different branch for tasting… oops, for testing. In this example, I’m opening the amd-gfx mailing list where I can find contributions related to the AMD GPU driver, bookmark and/or just apply the series to my work tree and with kw bd I can compile &amp; install the custom kernel with this possible bug fix in one shot.</p> <p>As I changed my kw config to reboot after deployment, I just need to wait for the system to boot to try again unloading the amdgpu driver with <code class="language-plaintext highlighter-rouge">kw debug --dmesg --cm=modprobe -r amdgpu</code>. From the dmesg output retrieved by kw for this command, the driver was unloaded, the problem is fixed by this series and the kernel tastes good now.</p> <p>If I’m satisfied with the solution, I can even use <code class="language-plaintext highlighter-rouge">kw patch-hub</code> to access the bookmarked series and marking the checkbox that will reply the patch thread with a <code class="language-plaintext highlighter-rouge">Reviewed-by</code> tag for me.</p> <h2 id="second-recipe-raspberry-pi-4-with-upstream-kernel">Second Recipe: Raspberry Pi 4 with Upstream Kernel</h2> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0025.png" alt="Slide 25: Second Recipe RPi 4 with upstream kernel" /></p> <p>As in all recipes, we need ingredients and tools, but with kworkflow you can get everything set as when changing scenarios in a TV show. We can use kw env to change to a different environment with all kw and kernel configuration set and also with the latest compiled kernel cached.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/081dc4299d5ebcd4365fa20b40d03f1a8f03ebf8/img/kr-2025/gifs/kw_env_to_rpi.gif" alt="" /></p> <p>I was preparing the first recipe for a <em>x86</em> AMD laptop and with <code class="language-plaintext highlighter-rouge">kw env --use RPI_64</code> I use the same worktree but moved to a different kernel workflow, now for Raspberry Pi 4 64 bits. The previous compiled kernel <code class="language-plaintext highlighter-rouge">6.17.0-rc6-mainline+</code> is there with 1266 modules, not the <code class="language-plaintext highlighter-rouge">6.17.0-rc6</code> kernel with 285 modules that I just built&amp;deployed. <code class="language-plaintext highlighter-rouge">kw build</code> settings are also different, now I’m targeting a arm64 architecture with a cross-compiled kernel using <code class="language-plaintext highlighter-rouge">aarch64-linu-gnu-</code> cross-compilation tool and my kernel image calls <code class="language-plaintext highlighter-rouge">kernel8</code> now.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0027.png" alt="Slide 27: kw env" /></p> <p>If you didn’t plan for this recipe in advance, don’t worry. You can create a new environment with <code class="language-plaintext highlighter-rouge">kw env --create RPI_64_V2</code> and run <code class="language-plaintext highlighter-rouge">kw init --template</code> to start preparing your kernel recipe with the mirepoix ready.</p> <p>I mean, with the basic ingredients already cut…</p> <p>I mean, with the kw configuration set from a template.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/55461efa4ce900f624abf3c5b6d1d8f63f201c3c/img/kr-2025/gifs/kw_init_template_rpi.gif" alt="" /></p> <p>And you can use <code class="language-plaintext highlighter-rouge">kw remote</code> to set the IP address of your target machine and <code class="language-plaintext highlighter-rouge">kw kernel-config-manager</code> to fetch/retrieve the .config file from your target machine. So just run <code class="language-plaintext highlighter-rouge">kw bd</code> to compile and install a upstream kernel for Raspberry Pi 4.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/081dc4299d5ebcd4365fa20b40d03f1a8f03ebf8/img/kr-2025/gifs/kw_env_rpi_bd.gif" alt="" /></p> <h2 id="third-recipe-the-mainline-kernel-ringing-on-my-steam-deck-live-demo">Third Recipe: The Mainline Kernel Ringing on my Steam Deck (Live Demo)</h2> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/kr-2025/pg_0032.png" alt="Slide 30: Third Recipe - The Mainline Kernel Ringing on my Steam Deck" /></p> <p>Let’s show you how easy is to build, install and test a custom kernel for Steam Deck with Kworkflow. It’s a live demo, but I also recorded it because I know the risks I’m exposed to and something can go very wrong just because of reasons :)</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/081dc4299d5ebcd4365fa20b40d03f1a8f03ebf8/img/kr-2025/gifs/kw_env_steamdeck_bd.gif" alt="" /></p> <h3 id="report-how-was-the-live-demo">Report: how was the live demo</h3> <p>For this live demo, I took my OLED Steam Deck to the stage. I explained that, if I boot mainline kernel on this device, there is no audio. So I turned it on and booted the mainline kernel I’ve installed beforehand. It was clear that there was no typical Steam Deck startup audio when the system was loaded.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/1cf7853f079996cfac5bf71d53809e24a42a4083/img/kr-2025/melissa1-scaled.jpg" alt="Franks drawing of Melissa Wen doing a demo of kworkflow with the Steam Deck" /></p> <p>As I started the demo in the kw environment for Raspberry Pi 4, I first moved to another environment previously used for Steam Deck. In this STEAMDECK environment, the mainline kernel was already compiled and cached, and all settings for accessing the target machine, compiling and installing a custom kernel were retrieved automatically.</p> <p>My live demo followed these steps:</p> <ol> <li> <p>With <code class="language-plaintext highlighter-rouge">kw env --use STEAMDECK</code>, switch to a kworkflow environment for Steam Deck kernel development.</p> </li> <li> <p>With <code class="language-plaintext highlighter-rouge">kw b -i</code>, shows that kw will compile and install a kernel with 285 modules named <code class="language-plaintext highlighter-rouge">6.17.0-rc6-mainline-for-deck</code>.</p> </li> <li> <p>Run <code class="language-plaintext highlighter-rouge">kw config</code> to show that, in this environment, kw configuration changes to x86 architecture and without cross-compilation.</p> </li> <li> <p>Run <code class="language-plaintext highlighter-rouge">kw device</code> to display information about the Steam Deck device, i.e. the target machine. It also proves that the remote access - user and IP - for this Steam Deck was already configured when using the STEAMDECK environment, as expected.</p> </li> <li> <p>Using <code class="language-plaintext highlighter-rouge">git am</code>, as usual, apply a hot fix on top of the mainline kernel. This hot fix makes the audio play again on Steam Deck.</p> </li> <li> <p>With <code class="language-plaintext highlighter-rouge">kw b</code>, build the kernel with the audio change. It will be fast because we are only compiling the affected files since everything was previously done and cached. Compiled kernel, kw configuration and kernel configuration is retrieved by just moving to the “STEAMDECK” environment.</p> </li> <li> <p>Run <code class="language-plaintext highlighter-rouge">kw d --force --reboot</code> to deploy the new custom kernel to the target machine. The <code class="language-plaintext highlighter-rouge">--force</code> option enables us to install the mainline kernel even if mkinitcpio complains about missing support for downstream packages when generating initramfs. The <code class="language-plaintext highlighter-rouge">--reboot</code> option makes the device reboot the Steam Deck automatically, just after the deployment completion.</p> </li> <li> <p>After finishing deployment, the Steam Deck will reboot on the new custom kernel version and made a clear resonant or vibrating sound. [Hopefully]</p> </li> </ol> <p>Finally, I showed to the audience that, if I wanted to send this patch upstream, I just needed to run <code class="language-plaintext highlighter-rouge">kw send-patch</code> and kw would automatically add subsystem maintainers, reviewers and mailing lists for the affected files as recipients, and send the patch to the upstream community assessment. As I didn’t want to create unnecessary noise, I just did a dry-run with <code class="language-plaintext highlighter-rouge">kw send-patch -s --simulate</code> to explain how it looks.</p> <h2 id="what-else-can-kworkflow-already-mix--match">What else can kworkflow already mix &amp; match?</h2> <p>In this presentation, I showed that kworkflow supported different kernel development workflows, i.e., multiple distributions, different bootloaders and architectures, different target machines, different debugging tools and automatize your kernel development routines best practices, from development environment setup and verifying a custom kernel in bare-metal to sending contributions upstream following the contributions-by-e-mail structure. I exemplified it with three different target machines: my ordinary x86 AMD laptop with Debian, Raspberry Pi 4 with arm64 Raspbian (cross-compilation) and the Steam Deck with SteamOS (x86 Arch-based OS). Besides those distributions, Kworkflow also supports Ubuntu, Fedora and PopOS.</p> <p><strong>Now it’s your turn: Do you have any secret recipes to share? Please share with us via kworkflow.</strong></p> <hr /> <h2 id="useful-links">Useful links</h2> <ul> <li><a href="https://www.youtube.com/watch?v=4FAepuchngU">Talk Recording of Kworkflow at Kernel Recipes 2025 on Igalia’s Channel</a></li> <li><a href="https://kernel-recipes.org/en/2025/schedule/kworkflow-mix-match-kernel-recipes-end-to-end/">Talk Abstract, Recording and Slide Deck of Kworkflow at Kernel Recipes 2025 on Kernel Recipes Website</a></li> <li><a href="https://github.com/melissawen/melissawen.github.io/raw/d3b00b4ade5b7dc14333c9ba3616c66d442ea7aa/img/kr-2025/KR-2025-Kworkflow-melissawen-slide-deck.pdf">Talk Slide Deck for Download with some Videos instead of GIFs</a></li> </ul> Mon, 03 Nov 2025 21:30:00 +0000 https://melissawen.github.io/blog/2025/11/03/kworkflow-talk-at-kernel-recipes-2025 https://melissawen.github.io/blog/2025/11/03/kworkflow-talk-at-kernel-recipes-2025 <p>This week, I reviewed the <a href="https://lore.kernel.org/dri-devel/20250430011115.223996-1-alex.hung@amd.com/">last available version of the Linux KMS Color API</a>. Specifically, I explored the proposed API by Harry Wentland and Alex Hung (AMD), their implementation for the AMD display driver and tracked the parallel <a href="https://lore.kernel.org/dri-devel/20250312072425.3099205-1-uma.shankar@intel.com/">efforts of Uma Shankar and Chaitanya Kumar Borah (Intel)</a> in bringing this plane color management to life. With this API in place, compositors will be able to provide better HDR support and advanced color management for Linux users.</p> <p>To get a hands-on feel for the API’s potential, I developed a fork of <code class="language-plaintext highlighter-rouge">drm_info</code> compatible with the new color properties. This allowed me to visualize the display hardware color management capabilities being exposed. If you’re curious and want to peek behind the curtain, you can find my exploratory work on the <a href="https://gitlab.freedesktop.org/mwen/drm_info/-/commits/kms_color">drm_info/kms_color branch</a>. The README there will guide you through the simple compilation and installation process.</p> <p><em>Note: You will need to update libdrm to match the proposed API. You can find an updated version in my personal repository <a href="https://gitlab.freedesktop.org/mwen/drm/-/tree/kms_color">here</a>. To avoid potential conflicts with your official <code class="language-plaintext highlighter-rouge">libdrm</code> installation, you can compile and install it in a local directory. Then, use the following command: <code class="language-plaintext highlighter-rouge">export LD_LIBRARY_PATH="/usr/local/lib/"</code></em></p> <p>In this post, I invite you to familiarize yourself with the new API that is about to be released. You can start doing as I did below: just deploy a custom kernel with the necessary patches and visualize the interface with the help of <code class="language-plaintext highlighter-rouge">drm_info</code>. Or, better yet, if you are a userspace developer, you can start developing user cases by experimenting with it.</p> <p>The more eyes the better.</p> <h3 id="kms-color-api-on-amd">KMS Color API on AMD</h3> <p>The great news is that AMD’s driver implementation for plane color operations is being developed right alongside their Linux KMS Color API proposal, so it’s easy to apply to your kernel branch and check it out. You can find details of their progress in <a href="https://lore.kernel.org/dri-devel/20250430011115.223996-1-alex.hung@amd.com/">the AMD’s series</a>.</p> <p>I just needed to compile a custom kernel with this series applied, intentionally leaving out the <code class="language-plaintext highlighter-rouge">AMD_PRIVATE_COLOR</code> flag. The <code class="language-plaintext highlighter-rouge">AMD_PRIVATE_COLOR</code> flag guards driver-specific color plane properties, which experimentally expose hardware capabilities while we don’t have the generic KMS plane color management interface available.</p> <p>If you don’t know or don’t remember the details of AMD driver specific color properties, you can learn more about this work in my blog posts <a href="https://melissawen.github.io/blog/2023/08/21/amd-steamdeck-colors">[1]</a> <a href="https://melissawen.github.io/blog/2023/11/07/amd-steamdeck-colors-p2">[2]</a> <a href="https://melissawen.github.io/blog/2023/12/20/xdc2023-colors-talk">[3]</a>. As driver-specific color properties and KMS colorops are redundant, the driver only advertises one of them, as you can see in <a href="https://lore.kernel.org/dri-devel/20250430011115.223996-25-alex.hung@amd.com/">AMD workaround patch 24</a>.</p> <p>So, with the custom kernel image ready, I installed it on a system powered by AMD DCN3 hardware (i.e. my Steam Deck). Using <a href="https://gitlab.freedesktop.org/mwen/drm_info/-/tree/kms_color">my custom drm_info</a>, I could clearly see the Plane Color Pipeline with eight color operations as below:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>└───"COLOR_PIPELINE" (atomic): enum {Bypass, Color Pipeline 258} = Bypass ├───Bypass └───Color Pipeline 258 ├───Color Operation 258 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = 1D Curve │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ └───"CURVE_1D_TYPE" (atomic): enum {sRGB EOTF, PQ 125 EOTF, BT.2020 Inverse OETF} = sRGB EOTF ├───Color Operation 263 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = Multiplier │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ └───"MULTIPLIER" (atomic): range [0, UINT64_MAX] = 0 ├───Color Operation 268 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = 3x4 Matrix │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ └───"DATA" (atomic): blob = 0 ├───Color Operation 273 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = 1D Curve │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ └───"CURVE_1D_TYPE" (atomic): enum {sRGB Inverse EOTF, PQ 125 Inverse EOTF, BT.2020 OETF} = sRGB Inverse EOTF ├───Color Operation 278 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = 1D LUT │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ ├───"SIZE" (atomic, immutable): range [0, UINT32_MAX] = 4096 │ ├───"LUT1D_INTERPOLATION" (immutable): enum {Linear} = Linear │ └───"DATA" (atomic): blob = 0 ├───Color Operation 285 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = 3D LUT │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ ├───"SIZE" (atomic, immutable): range [0, UINT32_MAX] = 17 │ ├───"LUT3D_INTERPOLATION" (immutable): enum {Tetrahedral} = Tetrahedral │ └───"DATA" (atomic): blob = 0 ├───Color Operation 292 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = 1D Curve │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ └───"CURVE_1D_TYPE" (atomic): enum {sRGB EOTF, PQ 125 EOTF, BT.2020 Inverse OETF} = sRGB EOTF └───Color Operation 297 ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, Multiplier, 3D LUT} = 1D LUT ├───"BYPASS" (atomic): range [0, 1] = 1 ├───"SIZE" (atomic, immutable): range [0, UINT32_MAX] = 4096 ├───"LUT1D_INTERPOLATION" (immutable): enum {Linear} = Linear └───"DATA" (atomic): blob = 0 </code></pre></div></div> <p>Note that Gamescope is currently using <a href="https://melissawen.github.io/blog/2023/12/20/xdc2023-colors-talk">AMD driver-specific color properties</a> implemented by me, Autumn Ashton and Harry Wentland. It doesn’t use this KMS Color API, and therefore <code class="language-plaintext highlighter-rouge">COLOR_PIPELINE</code> is set to <code class="language-plaintext highlighter-rouge">Bypass</code>. Once the API is accepted upstream, all users of the driver-specific API (including Gamescope) should switch to the KMS generic API, as this will be the official plane color management interface of the Linux kernel.</p> <h3 id="kms-color-api-on-intel">KMS Color API on Intel</h3> <p>On the Intel side, the driver implementation available upstream was built upon an earlier iteration of the API. This meant I had to apply a few tweaks to bring it in line with the latest specifications. You can explore their latest work <a href="https://lore.kernel.org/dri-devel/20250312072425.3099205-1-uma.shankar@intel.com/">here</a>. For a more simplified handling, combining the V9 of the Linux Color API, Intel’s contributions, and my necessary adjustments, check out <a href="https://gitlab.freedesktop.org/mwen/drm-misc/-/tree/intel_kms_color">my dedicated branch</a>.</p> <p>I then compiled a kernel from this integrated branch and deployed it on a system featuring Intel TigerLake GT2 graphics. Running <a href="https://gitlab.freedesktop.org/mwen/drm_info/-/tree/kms_color">my custom drm_info</a> revealed a Plane Color Pipeline with three color operations as follows:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>├───"COLOR_PIPELINE" (atomic): enum {Bypass, Color Pipeline 480} = Bypass │ ├───Bypass │ └───Color Pipeline 480 │ ├───Color Operation 480 │ │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, 1D LUT Mult Seg, 3x3 Matrix, Multiplier, 3D LUT} = 1D LUT Mult Seg │ │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ │ ├───"HW_CAPS" (atomic, immutable): blob = 484 │ │ └───"DATA" (atomic): blob = 0 │ ├───Color Operation 487 │ │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, 1D LUT Mult Seg, 3x3 Matrix, Multiplier, 3D LUT} = 3x3 Matrix │ │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ │ └───"DATA" (atomic): blob = 0 │ └───Color Operation 492 │ ├───"TYPE" (immutable): enum {1D Curve, 1D LUT, 3x4 Matrix, 1D LUT Mult Seg, 3x3 Matrix, Multiplier, 3D LUT} = 1D LUT Mult Seg │ ├───"BYPASS" (atomic): range [0, 1] = 1 │ ├───"HW_CAPS" (atomic, immutable): blob = 496 │ └───"DATA" (atomic): blob = 0 </code></pre></div></div> <p>Observe that Intel’s approach introduces additional properties like “HW_CAPS” at the color operation level, along with two new color operation types: 1D LUT with Multiple Segments and 3x3 Matrix. It’s important to remember that this implementation is based on an earlier stage of the KMS Color API and is awaiting review.</p> <h3 id="a-shout-out-to-those-who-made-this-happen">A Shout-Out to Those Who Made This Happen</h3> <p>I’m impressed by the solid implementation and clear direction of the V9 of the KMS Color API. It aligns with the many insightful discussions we’ve had over the past years. A huge thank you to Harry Wentland and Alex Hung for their dedication in bringing this to fruition!</p> <p>Beyond their efforts, I deeply appreciate Uma and Chaitanya’s commitment to updating Intel’s driver implementation to align with the freshest version of the KMS Color API. The collaborative spirit of the AMD and Intel developers in sharing their color pipeline work upstream is invaluable. We’re now gaining a much clearer picture of the color capabilities embedded in modern display hardware, all thanks to their hard work, comprehensive documentation, and engaging discussions.</p> <p>Finally, thanks all the userspace developers, color science experts, and kernel developers from various vendors who actively participate in the upstream discussions, meetings, workshops, each iteration of this API and the crucial code review process. I’m happy to be part of the final stages of this long kernel journey, but I know that when it comes to colors, one step is completed for new challenges to be unlocked.</p> <p>Looking forward to meeting you in this year Linux Display Next hackfest, organized by AMD in Toronto, to further discuss HDR, advanced color management, and other display trends.</p> Mon, 19 May 2025 22:05:00 +0100 https://melissawen.github.io/blog/2025/05/19/drm-info-with-kms-color-api https://melissawen.github.io/blog/2025/05/19/drm-info-with-kms-color-api <p>2025 was my first year at FOSDEM, and I can say it was an incredible experience where I met many colleagues from <a href="https://igalia.com">Igalia</a> who live around the world, and also many friends from the Linux display stack who are part of my daily work and contributions to DRM/KMS. In addition, I met new faces and recognized others with whom I had interacted on some online forums and we had good and long conversations.</p> <p>During <a href="https://fosdem.org/2025/">FOSDEM 2025</a> I had the opportunity to present about <a href="https://kworkflow.org/">kworkflow</a> in the kernel devroom. Kworkflow is a set of tools that help kernel developers with their routine tasks and it is the tool I use for my development tasks. In short, every contribution I make to the Linux kernel is assisted by kworkflow.</p> <p>The goal of my presentation was to spread the word about kworkflow. I aimed to show how the suite consolidates good practices and recommendations of the kernel workflow in short commands. These commands are easily configurable and memorized for your current work setup, or for your multiple setups.</p> <p>For me, Kworkflow is a tool that accommodates the needs of different agents in the Linux kernel community. Active developers and maintainers are the main target audience for kworkflow, but it is also inviting for users and user-space developers who just want to report a problem and validate a solution without needing to know every detail of the kernel development workflow.</p> <p>Something I didn’t emphasize during the presentation but would like to correct this flaw here is that the main author and developer of kworkflow is my colleague at Igalia, <a href="https://siqueira.tech/">Rodrigo Siqueira</a>. Being honest, my contributions are mostly on requesting and validating new features, fixing bugs, and sharing scripts to increase feature coverage.</p> <p>So, the video and slide deck of my FOSDEM presentation are available for download <a href="https://fosdem.org/2025/schedule/event/fosdem-2025-5733-don-t-let-your-motivation-go-save-time-with-kworkflow/">here</a>.</p> <iframe width="672" height="378" src="https://video.fosdem.org/2025/ud2208/fosdem-2025-5733-don-t-let-your-motivation-go-save-time-with-kworkflow.av1.webm" title="YouTube video - Kworkflow Talk at FOSDEM 2025" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe> <p>And, as usual, you will find in this blog post the script of this presentation and more detailed explanation of the demo presented there.</p> <hr /> <h2 id="kworkflow-at-fosdem-2025-speaker-notes-and-demo">Kworkflow at FOSDEM 2025: Speaker Notes and Demo</h2> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-01.png" alt="" /></p> <p>Hi, I’m Melissa, a GPU kernel driver developer at Igalia and today I’ll be giving a very inclusive talk to not let your motivation go by saving time with kworkflow.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-02.png" alt="" /></p> <p>So, you’re a kernel developer, or you want to be a kernel developer, or you don’t want to be a kernel developer. But you’re all united by a single need: you need to validate a custom kernel with just one change, and you need to verify that it fixes or improves something in the kernel.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-03.png" alt="" /> <img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-04.png" alt="" /> <img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-05.png" alt="" /></p> <p>And that’s a given change for a given distribution, or for a given device, or for a given subsystem…</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-07.png" alt="" /></p> <p>Look to this diagram and try to figure out the number of subsystems and related work trees you can handle in the kernel.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-08.png" alt="" /></p> <p>So, whether you are a kernel developer or not, at some point you may come across this type of situation:</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-09.png" alt="" /> There is a userspace developer who wants to report a kernel issue and says:</p> <ul> <li>Oh, there is a problem in your driver that can only be reproduced by running this specific distribution. And the kernel developer asks:</li> <li>Oh, have you checked if this issue is still present in the latest kernel version of this branch?</li> </ul> <p>But the userspace developer has never compiled and installed a custom kernel before. So they have to read a lot of tutorials and kernel documentation to create a kernel compilation and deployment script. Finally, the reporter managed to compile and deploy a custom kernel and reports:</p> <ul> <li>Sorry for the delay, this is the first time I have installed a custom kernel. I am not sure if I did it right, but the issue is still present in the kernel of the branch you pointed out.</li> </ul> <p>And then, the kernel developer needs to reproduce this issue on their side, but they have never worked with this distribution, so they just created a new script, but the same script created by the reporter.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-10.png" alt="" /></p> <p>What’s the problem of this situation? The problem is that you keep creating new scripts!</p> <p>Every time you change distribution, change architecture, change hardware, change project - even in the same company - the development setup may change when you switch to a different project, you create another script for your new kernel development workflow!</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-11.png" alt="" /></p> <p>You know, you have a lot of babies, you have a collection of “my precious scripts”, like Sméagol (Lord of the Rings) with the precious ring.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-12.png" alt="" /></p> <p>Instead of creating and accumulating scripts, save yourself time with kworkflow. Here is a typical script that many of you may have. This is a Raspberry Pi 4 script and contains everything you need to memorize to compile and deploy a kernel on your Raspberry Pi 4.</p> <p>With kworkflow, you only need to memorize two commands, and those commands are not specific to Raspberry Pi. They are the same commands to different architecture, kernel configuration, target device.</p> <h3 id="what-is-kworkflow">What is kworkflow?</h3> <p>Kworkflow is a collection of tools and software combined to:</p> <ul> <li>Optimize Linux kernel development workflow.</li> <li>Reduce time spent on repetitive tasks, since we are spending our lives compiling kernels.</li> <li>Standardize best practices.</li> <li>Ensure reliable data exchange across kernel workflow. For example: two people describe the same setup, but they are not seeing the same thing, kworkflow can ensure both are actually with the same kernel, modules and options enabled.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-14.png" alt="" /></p> <p>I don’t know if you will get this analogy, but kworkflow is for me a megazord of scripts. You are combining all of your scripts to create a very powerful tool.</p> <h3 id="what-is-the-main-feature-of-kworflow">What is the main feature of kworflow?</h3> <p>There are many, but these are the most important for me:</p> <ul> <li>Build &amp; deploy custom kernels <strong>across devices &amp; distros</strong>.</li> <li>Handle <strong>cross-compilation seamlessly</strong>.</li> <li>Manage <strong>multiple architecture, settings and target devices</strong> in the same work tree.</li> <li>Organize <strong>kernel configuration files</strong>.</li> <li>Facilitate <strong>remote debugging &amp; code inspection</strong>.</li> <li><strong>Standardize Linux kernel patch submission guidelines</strong>. You don’t need to double check documentantion neither Greg needs to tell you that you are not following Linux kernel guidelines.</li> <li><strong>Upcoming:</strong> Interface to bookmark, apply and “reviewed-by” patches from mailing lists (lore.kernel.org).</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-16.png" alt="" /></p> <p>This is the list of commands you can run with kworkflow. The first subset is to configure your tool for various situations you may face in your daily tasks.</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># Manage kw and kw configurations kw init - Initialize kw config file kw self-update (u) - Update kw kw config (g) - Manage kernel .config files </code></pre></div></div> <p>The second subset is to build and deploy custom kernels.</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># Build &amp; Deploy custom kernels kw kernel-config-manager (k) - Manage kernel .config files kw build (b) - Build kernel kw deploy (d) - Deploy kernel image (local/remote) kw bd - Build and deploy kernel </code></pre></div></div> <p>We have some tools to manage and interact with target machines.</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># Manage and interact with target machines kw ssh (s) - SSH support kw remote (r) - Manage machines available via ssh kw vm - QEMU support </code></pre></div></div> <p>To inspect and debug a kernel.</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># Inspect and debug kw device - Show basic hardware information kw explore (e) - Explore string patterns in the work tree and git logs kw debug - Linux kernel debug utilities kw drm - Set of commands to work with DRM drivers </code></pre></div></div> <p>To automatize best practices for patch submission like codestyle, maintainers and the correct list of recipients and mailing lists of this change, to ensure we are sending the patch to who is interested in it.</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># Automatize best practices for patch submission kw codestyle (c) - Check code style kw maintainers (m) - Get maintainers/mailing list kw send-patch - Send patches via email </code></pre></div></div> <p>And the last one, the upcoming patch hub.</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># Upcoming kw patch-hub - Interact with patches (lore.kernel.org) </code></pre></div></div> <h3 id="how-can-you-save-time-with-kworkflow">How can you save time with Kworkflow?</h3> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-17.png" alt="" /></p> <p>So how can you save time building and deploying a custom kernel?</p> <p>First, you need a .config file.</p> <ul> <li><strong>Without kworkflow:</strong> You may be manually extracting and managing .config files from different targets and saving them with different suffixes to link the kernel to the target device or distribution, or any descriptive suffix to help identify which is which. Or even copying and pasting from somewhere.</li> <li><strong>With kworkflow:</strong> you can use the kernel-config-manager command, or simply <code class="language-plaintext highlighter-rouge">kw k</code>, to store, describe and retrieve a specific .config file very easily, according to your current needs.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-18.png" alt="" /></p> <p>Then you want to build the kernel:</p> <ul> <li><strong>Without kworkflow:</strong> You are probably now memorizing a combination of commands and options.</li> <li><strong>With kworkflow:</strong> you just need <code class="language-plaintext highlighter-rouge">kw b</code> (kw build) to build the kernel with the correct settings for cross-compilation, compilation warnings, cflags, etc. It also shows some information about the kernel, like number of modules.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-19.png" alt="" /></p> <p>Finally, to deploy the kernel in a target machine.</p> <ul> <li><strong>Without kworkflow:</strong> You might be doing things like: SSH connecting to the remote machine, copying and removing files according to distributions and architecture, and manually updating the bootloader for the target distribution.</li> <li><strong>With kworkflow:</strong> you just need <code class="language-plaintext highlighter-rouge">kw d</code> which does a lot of things for you, like: deploying the kernel, preparing the target machine for the new installation, listing available kernels and uninstall them, creating a tarball, rebooting the machine after deploying the kernel, etc.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-20.png" alt="" /></p> <p>You can also save time on debugging kernels locally or remotely.</p> <ul> <li><strong>Without kworkflow:</strong> you do: ssh, manual setup and traces enablement, copy&amp;paste logs.</li> <li><strong>With kworkflow:</strong> more straighforward access to debug utilities: events, trace, dmesg.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-21.png" alt="" /></p> <p>You can save time on managing multiple kernel images in the same work tree.</p> <ul> <li><strong>Without kworkflow:</strong> now you can be cloning multiple times the same repository so you don’t lose compiled files when changing kernel configuration or compilation options and manually managing build and deployment scripts.</li> <li><strong>With kworkflow:</strong> you can use <code class="language-plaintext highlighter-rouge">kw env</code> to isolate multiple contexts in the same worktree as environments, so you can keep different configurations in the same worktree and switch between them easily without losing anything from the last time you worked in a specific context.</li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-22.png" alt="" /></p> <p>Finally, you can save time when submitting kernel patches. In kworkflow, you can find everything you need to wrap your changes in patch format and submit them to the right list of recipients, those who can review, comment on, and accept your changes.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-patch-hub.gif" alt="" /></p> <p>This is a demo that the lead developer of the kw patch-hub feature sent me. With this feature, you will be able to check out a series on a specific mailing list, bookmark those patches in the kernel for validation, and when you are satisfied with the proposed changes, you can automatically submit a reviewed-by for that whole series to the mailing list.</p> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-fosdem-2024-talk-24.png" alt="" /></p> <hr /> <h3 id="demo">Demo</h3> <p>Now a demo of how to use kw environment to deal with different devices, architectures and distributions in the same work tree without losing compiled files, build and deploy settings, .config file, remote access configuration and other settings specific for those three devices that I have.</p> <h4 id="setup">Setup</h4> <ul> <li>Three devices: <ul> <li> <table> <tbody> <tr> <td>laptop (debian</td> <td>x86</td> <td>intel</td> <td>local)</td> </tr> </tbody> </table> </li> <li> <table> <tbody> <tr> <td>SteamDeck (steamos</td> <td>x86</td> <td>amd</td> <td>remote)</td> </tr> </tbody> </table> </li> <li> <table> <tbody> <tr> <td>RaspberryPi 4 (raspbian</td> <td>arm64</td> <td>broadcomm</td> <td>remote)</td> </tr> </tbody> </table> </li> </ul> </li> <li>Goal: To validate a change on DRM/VKMS using a single kernel tree.</li> <li>Kworkflow commands: <ul> <li>kw env</li> <li>kw d</li> <li>kw bd</li> <li>kw device</li> <li>kw debug</li> <li>kw drm</li> </ul> </li> </ul> <p><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/fosdem-2025-talk/kworkflow-env.gif" alt="" /></p> <h4 id="demo-script">Demo script</h4> <p>In the same terminal and worktree.</p> <h5 id="first-target-device-laptop-debianx86intellocal">First target device: Laptop (debian|x86|intel|local)</h5> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ kw env --list # list environments available in this work tree $ kw env --use LOCAL # select the environment of local machine (laptop) to use: loading pre-compiled files, kernel and kworkflow settings. $ kw device # show device information $ sudo modinfo vkms # show VKMS module information before applying kernel changes. $ &lt;open VKMS file and change module info&gt; $ kw bd # compile and install kernel with the given change $ sudo modinfo vkms # show VKMS module information after kernel changes. $ git checkout -- drivers </code></pre></div></div> <h5 id="second-target-device-raspberrypi-4-raspbianarm64broadcommremote">Second target device: RaspberryPi 4 (raspbian|arm64|broadcomm|remote)</h5> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ kw env --use RPI_64 # move to the environment for a different target device. $ kw device # show device information and kernel image name $ kw drm --gui-off-after-reboot # set the system to not load graphical layer after reboot $ kw b # build the kernel with the VKMS change $ kw d --reboot # deploy the custom kernel in a Raspberry Pi 4 with Raspbian 64, and reboot $ kw s # connect with the target machine via ssh and check the kernel image name $ exit </code></pre></div></div> <h5 id="third-target-device-steamdeck-steamosx86amdremote">Third target device: SteamDeck (steamos|x86|amd|remote)</h5> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ kw env --use STEAMDECK # move to the environment for a different target device $ kw device # show device information $ kw debug --dmesg --follow --history --cmd="modprobe vkms" # run a command and show the related dmesg output $ kw debug --dmesg --follow --history --cmd="modprobe -r vkms" # run a command and show the related dmesg output $ &lt;add a printk with a random msg to appear on dmesg log&gt; $ kw bd # deploy and install custom kernel to the target device $ kw debug --dmesg --follow --history --cmd="modprobe vkms" # run a command and show the related dmesg output after build and deploy the kernel change </code></pre></div></div> <hr /> <h3 id="qa">Q&amp;A</h3> <p>Most of the questions raised at the end of the presentation were actually suggestions and additions of new features to kworkflow.</p> <p>The first participant, that is also a kernel maintainer, asked about two features: (1) automatize getting patches from patchwork (or lore) and triggering the process of building, deploying and validating them using the existing workflow, (2) bisecting support. They are both very interesting features. The first one fits well the patch-hub subproject, that is under-development, and I’ve actually made <a href="https://github.com/kworkflow/kworkflow/issues/1177">a similar request</a> a couple of weeks before the talk. The second is an <a href="https://github.com/kworkflow/kworkflow/issues/664">already existing request</a> in kworkflow github project.</p> <p>Another request was to use kexec and avoid rebooting the kernel for testing. Reviewing my presentation I realized I wasn’t very clear that kworkflow doesn’t support kexec. As I replied, what it does is to install the modules and you can load/unload them for validations, but for built-in parts, you need to reboot the kernel.</p> <p>Another two questions: one about Android Debug Bridge (ADB) support instead of SSH and another about support to alternative ways of booting when the custom kernel ended up broken but you only have one kernel image there. Kworkflow doesn’t manage it yet, but I agree this is a very useful feature for embedded devices. On Raspberry Pi 4, kworkflow mitigates this issue by preserving the distro kernel image and using config.txt file to set a custom kernel for booting. For ADB, there is no support too, and as I don’t see currently users of KW working with Android, I don’t think we will have this support any time soon, except if we find new volunteers and increase the pool of contributors.</p> <p>The last two questions were regarding the status of b4 integration, that is under development, and other debugging features that the tool doesn’t support yet.</p> <p>Finally, when Andrea and I were changing turn on the stage, he suggested to add support for <a href="https://github.com/arighi/virtme-ng">virtme-ng</a> to kworkflow. So I opened an <a href="https://github.com/kworkflow/kworkflow/issues/1189">issue</a> for tracking this feature request in the project github.</p> <p>With all these questions and requests, I could see the general need for a tool that integrates the variety of kernel developer workflows, as proposed by kworflow. Also, there are still many cases to be covered by kworkflow.</p> <p>Despite the high demand, this is a completely voluntary project and it is unlikely that we will be able to meet these needs given the limited resources. We will keep trying our best in the hope we can increase the pool of users and contributors too.</p> Tue, 22 Apr 2025 20:30:00 +0100 https://melissawen.github.io/blog/2025/04/22/fosdem-2025-kernel-devroom-kworkflow-talk https://melissawen.github.io/blog/2025/04/22/fosdem-2025-kernel-devroom-kworkflow-talk <p>XDC 2024 in Montreal was another fantastic gathering for the Linux Graphics community. It was again a great time to immerse in the world of graphics development, engage in stimulating conversations, and learn from inspiring developers.</p> <p>Many <a href="https://igalia.com/">Igalia</a> colleagues and I participated in the conference again, delivering multiple talks about our work on the Linux Graphics stack and also organizing the Display/KMS meeting. This blog post is a detailed report on the Display/KMS meeting held during this XDC edition.</p> <p><strong>Short on Time?</strong></p> <ol> <li>Catch the lightning talk summarizing the meeting here (you can even speed up 2x):</li> </ol> <iframe width="560" height="315" src="https://www.youtube.com/embed/ww3KlaeCfzY?si=fUGveICjtK9fmx5o&amp;start=209" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen=""></iframe> <ol> <li>For a quick written summary, scroll down to the TL;DR section.</li> </ol> <h2 id="tldr">TL;DR</h2> <p>This meeting took 3 hours and tackled a variety of topics related to DRM/KMS (Linux/DRM Kernel Modesetting):</p> <ul> <li><strong>Sharing Drivers Between V4L2 and KMS:</strong> Brainstorming solutions for using a single driver for devices used in both camera capture and display pipelines.</li> <li><strong>Real-Time Scheduling:</strong> Addressing issues with non-blocking page flips encountering sigkills under real-time scheduling.</li> <li><strong>HDR/Color Management:</strong> Agreement on merging the current proposal, with NVIDIA implementing its special cases on VKMS and adding missing parts on top of Harry Wentland’s (AMD) changes.</li> <li><strong>Display Mux:</strong> Collaborative design discussions focusing on compositor control and cross-sync considerations.</li> <li><strong>Better Commit Failure Feedback:</strong> Exploring ways to equip compositors with more detailed information for failure analysis.</li> </ul> <hr /> <h2 id="bringing-together-linux-display-developers-in-the-xdc-2024">Bringing together Linux display developers in the XDC 2024</h2> <p>While I didn’t present a talk this year, I co-organized a Display/KMS meeting (with Rodrigo Siqueira of AMD) to build upon the momentum from the <a href="https://events.pages.igalia.com/linuxdisplaynexthackfest/">2024 Linux Display Next hackfest</a>. The meeting was attended by around 30 people in person and 4 remote participants.</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-room-2.jpg" title="Display/KMS meeting room with around 30 in-person participants, a large screen with remote participants and Jonas Adahl on the stage."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-room-2.jpg" alt="" /></a></p> <p><strong>Speakers:</strong> Melissa Wen (Igalia) and Rodrigo Siqueira (AMD)</p> <p><strong>Link:</strong> https://indico.freedesktop.org/event/6/contributions/383/</p> <p><strong>Topics:</strong> Similar to the hackfest, the meeting agenda was built over the first two days of the conference and mixed talks follow-up with new ideas and ongoing community efforts.</p> <p>The final agenda covered five topics in the scheduled order:</p> <ol> <li>How to share drivers between V4L2 and DRM for bridge-like components (new topic);</li> <li>Real-time Scheduling (problems encountered after the Display Next hackfest);</li> <li>HDR/Color Management (ofc);</li> <li>Display Mux (from Display hackfest and XDC 2024 talk, bringing AMD and NVIDIA together);</li> <li>(Better) Commit Failure Feedback (continuing the last minute topic of the Display Next hackfest).</li> </ol> <h2 id="unpacking-the-topics">Unpacking the Topics</h2> <p>Similar to the hackfest, the meeting agenda evolved over the conference. During the 3 hours of meeting, I coordinated the room and discussion rounds, and Rodrigo Siqueira took notes and also contacted key developers to provide a detailed report of the many topics discussed.</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-summary.jpg" title="Melissa Wen and Rodrigo Siqueira presents a lightning talk that summarizes the Display/KMS meeting - with some slides."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-summary.jpg" alt="" /></a></p> <p>From his notes, let’s dive into the key discussions!</p> <h3 id="how-to-share-drivers-between-v4l2-and-kms-for-bridge-like-components">How to share drivers between V4L2 and KMS for bridge-like components.</h3> <p>Led by <em>Laurent Pinchart</em>, we delved into the challenge of creating a unified driver for hardware devices (like scalers) that are used in both camera capture pipelines and display pipelines.</p> <ul> <li><strong>Problem Statement:</strong> How can we design a single kernel driver to handle devices that serve dual purposes in both V4L2 and DRM subsystems?</li> <li><strong>Potential Solutions:</strong> <ol> <li><em>Multiple Compatible Strings:</em> We could assign different compatible strings to the device tree node based on its usage in either the camera or display pipeline. However, this approach might raise concerns from device tree maintainers as it could be seen as a layer violation.</li> <li><em>Separate Abstractions:</em> A single driver could expose the device to both DRM and V4L2 through separate abstractions: drm-bridge for DRM and V4L2 subdev for video. While simple, this approach requires maintaining two different abstractions for the same underlying device.</li> <li><em>Unified Kernel Abstraction:</em> We could create a new, unified kernel abstraction that combines the best aspects of drm-bridge and V4L2 subdev. This approach offers a more elegant solution but requires significant design effort and potential migration challenges for existing hardware.</li> </ol> </li> </ul> <h3 id="real-time-scheduling-challenges">Real-Time Scheduling Challenges</h3> <p>We have discussed real-time scheduling during <a href="https://events.pages.igalia.com/linuxdisplaynexthackfest/">this year Linux Display Next hackfest</a> and, during the XDC 2024, <em>Jonas Adahl</em> brought up issues uncovered while progressing on this front.</p> <ul> <li><strong>Context:</strong> Non-blocking page-flips can, on rare occasions, take a long time and, for that reason, get a sigkill if the thread doing the atomic commit is a real-time schedule.</li> <li><strong>Action items</strong>: <ul> <li>Explore alternative backtraces during the busy wait (e.g., ftrace).</li> <li>Investigate the maximum thread time in busy wait to reproduce issues faced by compositors. Tools like RTKit (mutter) can be used for better control (Michel Dänzer can help with this setup).</li> </ul> </li> </ul> <h3 id="hdrcolor-management">HDR/Color Management</h3> <p>This is a well-known topic with ongoing effort on all layers of the Linux Display stack and has been discussed online and in-person in conferences and meetings over the last years.</p> <p>Here’s a breakdown of the key points raised at this meeting:</p> <ul> <li><strong><a href="https://www.youtube.com/watch?v=623tXWWz9lc">Talk: Color operations for Linux color pipeline on AMD devices</a></strong>: In the previous day, Alex Hung (AMD) presented the implementation of this API on AMD display driver.</li> <li><strong>NVIDIA Integration</strong>: While they agree with the overall proposal, NVIDIA needs to add some missing parts. Importantly, they will implement these on top of Harry Wentland’s (AMD) proposal. Their specific requirements will be implemented on VKMS (Virtual Kernel Mode Setting driver) for further discussion. This VKMS implementation can benefit compositor developers by providing insights into NVIDIA’s specific needs.</li> <li><strong>Other vendors</strong>: There is a version of the KMS API applied on Intel color pipeline. Apart from that, other vendors appear to be comfortable with the current proposal but lacks the bandwidth to implement it right now.</li> <li><strong>Upstream Patches</strong>: The relevant upstream patches were can be found <a href="https://lore.kernel.org/dri-devel/20241003200129.1732122-1-harry.wentland@amd.com/">here</a>. <em>[As humorously notes, this series is eagerly awaiting your “Acked-by” (approval)]</em></li> <li><strong>Compositor Side</strong>: The compositor developers have also made significant progress. <ul> <li>KDE has already implemented and validated the API through <a href="https://invent.kde.org/plasma/kwin/-/commits/work/zamundaaa/drm-colorop">an experimental implementation in Kwin</a>.</li> <li>Gamescope currently uses a driver-specific implementation but has <a href="https://github.com/ValveSoftware/gamescope/pull/1309">a draft</a> that utilizes the generic version. However, some work is still required to fully transition away from the driver-specific approach. <em>AP: work on porting gamescope to KMS generic API</em></li> <li>Weston has also begun exploring implementation, and we might see something from them by the end of the year.</li> </ul> </li> <li><strong>Kernel and Testing</strong>: The kernel API proposal is well-refined and meets the DRM subsystem requirements. Thanks to <em>Harry Wentland</em> effort, we already have <a href="https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1">the API attached to two hardware vendors</a> and <a href="https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5">IGT tests</a>, and, thanks to <em>Xaver Hugl</em>, a compositor implementation in place.</li> </ul> <p>Finally, there was a strong sense of agreement that the current proposal for HDR/Color Management is ready to be merged. In simpler terms, everything seems to be working well on the technical side - all signs point to merging and “shipping” the DRM/KMS plane color management API!</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-summary-2.jpg" title="Melissa Wen summarizes the HDR/Color Management discussions in the Display/KMS meeting."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-summary-2.jpg" alt="" /></a></p> <h3 id="display-mux">Display Mux</h3> <p>During the meeting, <em>Daniel Dadap</em> led a brainstorming session on the design of the display mux switching sequence, in which the compositor would arm the switch via sysfs, then send a modeset to the outgoing driver, followed by a modeset to the incoming driver.</p> <ul> <li><strong>Context:</strong> <ul> <li>During this year Linux Display Next hackfest, Mario Limonciello (AMD) introduced the topic and led a discussion on <a href="https://cloud.igalia.com/s/7Z5xdAQiN5pz6GC">Display Mux</a>.</li> <li>Daniel Dadap (NVIDIA) retook this discussion with the <a href="https://www.youtube.com/watch?v=gTTKmLa0urU">XDC 2024 talk: Dynamic Switching of Display Muxes on Hybrid GPU Systems</a>.</li> </ul> </li> <li><strong>Key Considerations:</strong> <ul> <li><em>HPD Handling:</em> There was a general consensus that disabling HPD can be part of the sequence for internal panels and we don’t need to focus on it here.</li> <li><em>Cross-Sync:</em> Ensuring synchronization between the compositor and the drivers is crucial. The compositor should act as the “drm-master” to coordinate the entire sequence, but how can this be ensured?</li> <li><em>Future-Proofing:</em> The design should not assume the presence of a mux. In future scenarios, direct sharing over DP might be possible.</li> </ul> </li> <li><strong>Action points:</strong> <ul> <li><em>Sharing DP AUX:</em> Explore the idea of sharing DP AUX and its implications.</li> <li><em>Backlight</em>: The backlight definition represents a problem in the mux switch context, so we should explore some of the current specs available for that.</li> </ul> </li> </ul> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-room.jpg" title="The Display/KMS meeting room with Daniel Dadap and Harry Wentland discussing about Display Mux."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/xdc2024/xdc2024-display-meeting-room.jpg" alt="" /></a></p> <h3 id="towards-better-commit-failure-feedback">Towards Better Commit Failure Feedback</h3> <p>In the last part of the meeting, <em>Xaver Hugl</em> asked for better commit failure feedback.</p> <ul> <li><strong>Problem description:</strong> Compositors currently face challenges in collecting detailed information from the kernel about commit failures. This lack of granular data hinders their ability to understand and address the root causes of these failures.</li> </ul> <p>To address this issue, we discussed <strong>several potential improvements</strong>:</p> <ul> <li><em>Direct Kernel Log Access:</em> One idea is to directly load relevant kernel logs into the compositor. This would provide more detailed information about the failure and potentially aid in debugging.</li> <li><em>Finer-Grained Failure Reporting:</em> We also explored the possibility of separating atomic failures into more specific categories. Not all failures are critical, and understanding the nature of the failure can help compositors take appropriate action.</li> <li><em>Enhanced Logging:</em> Currently, the dmesg log doesn’t provide enough information for user-space validation. Raising the log level to capture more detailed information during failures could be a viable solution.</li> </ul> <p>By implementing these improvements, we aim to equip compositors with the necessary tools to better understand and resolve commit failures, leading to a more robust and stable display system.</p> <h2 id="a-big-thank-you">A Big Thank You!</h2> <p>Huge thanks to Rodrigo Siqueira for these detailed meeting notes. Also, Laurent Pinchart, Jonas Adahl, Daniel Dadap, Xaver Hugl, and Harry Wentland for bringing up interesting topics and leading discussions. Finally, thanks to all the participants who enriched the discussions with their experience, ideas, and inputs, especially Alex Goins, Antonino Maniscalco, Austin Shafer, Daniel Stone, Demi Obenour, Jessica Zhang, Joan Torres, Leo Li, Liviu Dudau, Mario Limonciello, Michel Dänzer, Rob Clark, Simon Ser and Teddy Li.</p> <p>This collaborative effort will undoubtedly contribute to the continued development of the Linux display stack.</p> <p><strong>Stay tuned for future updates!</strong></p> Tue, 19 Nov 2024 13:00:00 +0000 https://melissawen.github.io/blog/2024/11/19/summary-display-kms-meeting-xdc2024 https://melissawen.github.io/blog/2024/11/19/summary-display-kms-meeting-xdc2024 <p>Hey everyone!</p> <p>The <a href="https://events.pages.igalia.com/linuxdisplaynexthackfest/">2024 Linux Display Next hackfest</a> concluded in May, and its outcomes continue to shape the Linux Display stack. Igalia hosted this year’s event in A Coruña, Spain, bringing together leading experts in the field. <a href="https://blogs.igalia.com/siglesias/">Samuel Iglesias</a> and I organized this year’s edition and this blog post summarizes the experience and its fruits.</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-0.jpg" title="Hackfest main room: preparation before starting the first day with organizers and some participants in the main room checking schedule and chatting."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-0.jpg" alt="" /></a></p> <p>One of the highlights of this year’s hackfest was the wide range of backgrounds represented by our 40 participants (both on-site and remotely). Developers and experts from various companies and open-source projects came together to advance the Linux Display ecosystem. You can find the list of participants <a href="https://github.com/melissawen/2024linuxdisplayhackfest/wiki/list-of-participants">here</a>.</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-1.jpg" title="Hackfest main room: in-person participants seated at tables arranged in a U shape, with microphones, laptops, projector and a large screen."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-1.jpg" alt="" /></a></p> <p>The event covered a broad spectrum of topics affecting the development of Linux projects, user experiences, and the future of display technologies on Linux. From cutting-edge topics to long-term discussions, you can check the event agenda <a href="https://github.com/melissawen/2024linuxdisplayhackfest/issues/11">here</a>.</p> <h2 id="organization-highlights">Organization Highlights</h2> <p>The hackfest was marked by in-depth discussions and knowledge sharing among Linux contributors, making everyone inspired, informed, and connected to the community. Building on feedback from the previous year, we refined the unconference format to enhance participant preparation and engagement.</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-2.jpg" title="Hackfest main room: laptop screen showing in-person participants in the hackfest room on Jitsi."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-2.jpg" alt="" /></a></p> <p><strong>Structured Agenda and Timeboxes:</strong> Each session had a defined scope, time limit (1h20 or 2h10), and began with an introductory talk on the topic.</p> <ul> <li><strong>Participant-Led Discussions:</strong> We pre-selected in-person participants to lead discussions, allowing them to prepare introductions, resources, and scope.</li> <li><strong>Transparent Scheduling:</strong> The schedule was shared in advance as GitHub issues, encouraging participants to review and prepare for sessions of interest.</li> </ul> <p><strong>Engaging Sessions:</strong> The hackfest featured a variety of topics, including presentations and discussions on how participants were addressing specific subjects within their companies.</p> <ul> <li><strong>No Breakout Rooms, No Overlaps:</strong> All participants chose to attend all sessions, eliminating the need for separate breakout rooms. We also adapted run-time schedule to keep everybody involved in the same topics.</li> <li><strong>Real-time Updates:</strong> We provided notifications and updates through dedicated emails and the event matrix room.</li> </ul> <p><strong>Strengthening Community Connections:</strong> The hackfest offered ample opportunities for networking among attendees.</p> <ul> <li> <p><strong>Social Events:</strong> Igalia sponsored coffee breaks, lunches, and a dinner at a local restaurant. <a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/artabria.jpg" title="First-day dinner at Artabria restaurant: large table with all participants."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/artabria.jpg" alt="" /></a></p> </li> <li> <p><strong>Museum Visit:</strong> Participants enjoyed a sponsored visit to the Museum of Estrela Galicia Beer (MEGA). <a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/mega-ppl.jpg" title="Guided tour at MEGA: participants tasting beers in the end of the guided tour at Museum Estrela Galicia."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/mega-ppl.jpg" alt="" /></a></p> </li> </ul> <h2 id="fruitful-discussions-and-follow-up">Fruitful Discussions and Follow-up</h2> <p>The structured agenda and breaks allowed us to cover multiple topics during the hackfest. These discussions have led to new display feature development and improvements, as evidenced by patches, merge requests, and implementations in project repositories and mailing lists.</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-discussions.jpg" title="Hackfest main room: participants discussions with Alex Goins speaking"><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-discussions.jpg" alt="" /></a></p> <p>With the KMS color management API taking shape, we discussed refinements and best approaches to cover the variety of color pipeline from different hardware-vendors. We are also investigating techniques for a performant SDR&lt;-&gt;HDR content reproduction and reducing latency and power consumption when using the color blocks of the hardware.</p> <h3 id="color-managementhdr">Color Management/HDR</h3> <p>Color Management and HDR continued to be the hottest topic of the hackfest. We had three sessions dedicated to discuss Color and HDR across Linux Display stack layers.</p> <h4 id="colorhdr-kernel-level">Color/HDR (Kernel-Level)</h4> <p>Harry Wentland (AMD) led this session.</p> <p>Here, kernel Developers shared the Color Management pipeline of AMD, Intel and NVidia. We counted with diagrams and explanations from HW-vendors developers that discussed differences, constraints and paths to fit them into the KMS generic color management properties such as advertising modeset needs, <code class="language-plaintext highlighter-rouge">IN\_FORMAT</code>, <a href="https://github.com/ckborah/drm-tip-sandbox/commit/86441c236c9e16a430b629f0a278b444ec1960c8#diff-dab99b769a18136804a5e52ebb50648438500b97f6c42fcdb69fa0668bffff88R3814">segmented LUTs</a>, interpolation types, etc. Developers from Qualcomm and ARM also added information regarding their hardware.</p> <p>Upstream work related to this session:</p> <ul> <li><a href="https://lore.kernel.org/dri-devel/20240819205714.316380-1-harry.wentland@amd.com/">KMS color management properties (new version - v5)</a>;</li> <li><a href="https://lore.kernel.org/igt-dev/20240819205823.316656-1-harry.wentland@amd.com/">IGT Tests</a>;</li> <li><a href="https://gitlab.freedesktop.org/mwen/drm_info/-/merge_requests/1">drm_info draft support of v4 DRM/KMS plane color properties</a>;</li> <li><a href="https://github.com/ValveSoftware/gamescope/pull/1309">gamescope draft support of v4 DRM/KMS plane color properties</a>;</li> <li><a href="https://lore.kernel.org/amd-gfx/CAFZQkGzLjCOSPvk0kYYXyJm8E6Szdw9PJUcUQzew-EBfQjzz_g@mail.gmail.com/">Kwin WIP implementation of DRM/KMS plane color properties</a>.</li> </ul> <h4 id="colorhdr-compositor-level">Color/HDR (Compositor-Level)</h4> <p>Sebastian Wick (RedHat) led this session.</p> <p>It started with Sebastian’s presentation covering Wayland color protocols and compositor implementation. Also, an explanation of APIs provided by Wayland and how they can be used to achieve better color management for applications and discussions around ICC profiles and color representation metadata. There was also an intensive Q&amp;A about LittleCMS with Marti Maria.</p> <p>Upstream work related to this session:</p> <ul> <li><a href="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14">Wayland color management protocol</a>;</li> <li><a href="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183">Wayland color representation protocol</a>;</li> <li><a href="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433">HDR support merged on Mutter</a>;</li> <li><a href="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3893">Color management protocol on Mutter</a>;</li> <li><a href="https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7444">Color management protocol on GTK</a>.</li> </ul> <h4 id="colorhdr-use-cases-and-testing">Color/HDR (Use Cases and Testing)</h4> <p>Christopher Cameron (Google) and Melissa Wen (Igalia) led this session.</p> <p>In contrast to the other sessions, here we focused less on implementation and more on brainstorming and reflections of real-world SDR and HDR transformations (use and validation) and gainmaps. Christopher gave a nice presentation explaining HDR gainmap images and how we should think of HDR. This presentation and Q&amp;A were important to put participants at the same page of how to transition between SDR and HDR and somehow “emulating” HDR.</p> <p>We also discussed on the usage of a kernel background color property.</p> <p>Finally, we discussed a bit about <a href="https://www.chromium.org/chromium-os/developer-library/guides/hardware-schematics/chamelium/">Chamelium</a> and the future of VKMS (future work and maintainership).</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-discussions-2.jpg" title="Hackfest main room: participants discussions with Chris Cameron speaking."><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-discussions-2.jpg" alt="" /></a></p> <h3 id="power-savings-vs-colorlatency">Power Savings vs Color/Latency</h3> <p>Mario Limonciello (AMD) led this session.</p> <p>Mario gave an introductory presentation about AMD ABM (adaptive backlight management) that is similar to Intel DPST. After some discussions, we agreed on exposing a kernel property for power saving policy. This work was already merged on kernel and the userspace support is under development.</p> <p>Upstream work related to this session:</p> <ul> <li><a href="https://patchwork.freedesktop.org/series/135675/">Kernel series: Add support for ‘power saving policy’ property (merged)</a></li> <li><a href="https://gitlab.gnome.org/GNOME/mutter/-/issues/3589">Mutter: issue: support for “power saving policy” property</a></li> <li><a href="https://invent.kde.org/plasma/kwin/-/merge_requests/6028">Kwin: MR Draft: backends/drm: add support for the “power saving policy” property</a></li> </ul> <h3 id="strategy-for-video-and-gaming-use-cases">Strategy for video and gaming use-cases</h3> <p>Leo Li (AMD) led this session.</p> <p>Miguel Casas (Google) started this session with a presentation of Overlays in Chrome/OS Video, explaining the main goal of power saving by switching off GPU for accelerated compositing and the challenges of different colorspace/HDR for video on Linux.</p> <p>Then Leo Li presented different strategies for video and gaming and we discussed the userspace need of more detailed feedback mechanisms to understand failures when offloading. Also, creating a debugFS interface came up as a tool for debugging and analysis.</p> <h3 id="real-time-scheduling-and-async-kms-api">Real-time scheduling and async KMS API</h3> <p>Xaver Hugl (KDE/BlueSystems) led this session.</p> <p>Compositor developers have exposed some issues with doing real-time scheduling and async page flips. One is that the Kernel limits the lifetime of realtime threads and if a modeset takes too long, the thread will be killed and thus the compositor as well. Also, simple page flips take longer than expected and drivers should optimize them.</p> <p>Another issue is the lack of feedback to compositors about hardware programming time and commit deadlines (the lastest possible time to commit). This is difficult to predict from drivers, since it varies greatly with the type of properties. For example, color management updates take much longer.</p> <p>In this regard, we discusssed implementing a <code class="language-plaintext highlighter-rouge">hw_done</code> callback to timestamp when the hardware programming of the last atomic commit is complete. Also an API to pre-program color pipeline in a kind of A/B scheme. It may not be supported by all drivers, but might be useful in different ways.</p> <h3 id="vrrframe-limit-display-mux-display-control-and-more-and-beer">VRR/Frame Limit, Display Mux, Display Control, and more… and beer</h3> <p>We also had sessions to discuss a new KMS API to mitigate headaches on <strong>VRR and Frame Limit</strong> as different brightness level at different refresh rates, abrupt changes of refresh rates, low frame rate compensation (LFC) and precise timing in VRR more.</p> <p>On <strong>Display Control</strong> we discussed features missing in the current KMS interface for HDR mode, atomic backlight settings, source-based tone mapping, etc. We also discussed the need of a place where compositor developers can post TODOs to be developed by KMS people.</p> <p>The <strong>Content-adaptive Scaling and Sharpening</strong> session focused on sharpening and scaling filters. In the <strong>Display Mux</strong> session, we discussed proposals to expose the capability of dynamic mux switching display signal between discrete and integrated GPUs.</p> <p>In the <strong>last session of the 2024 Display Next Hackfest</strong>, participants representing different compositors summarized current and future work and built a Linux Display “wish list”, which includes: improvements to VTTY and HDR switching, better dmabuf API for multi-GPU support, definition of tone mapping, blending and scaling sematics, and wayland protocols for advertising to clients which colorspaces are supported.</p> <p>We closed this session with a status update on feature development by compositors, including but not limited to: plane offloading (from libcamera to output) / HDR video offloading (dma-heaps) / plane-based scrolling for web pages, color management / HDR / ICC profiles support, addressing issues such as flickering when color primaries don’t match, etc.</p> <p>After three days of intensive discussions, all in-person participants went to a guided tour at the Museum of Extrela Galicia beer (MEGA), pouring and tasting the most famous local beer.</p> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/mega-pouring.jpg" title="Guided tour at MEGA: participants pouring beer"><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/mega-pouring.jpg" alt="" /></a></p> <h2 id="feedback-and-future-directions">Feedback and Future Directions</h2> <p>Participants provided valuable feedback on the hackfest, including suggestions for future improvements.</p> <ul> <li><strong>Schedule and Break-time Setup:</strong> Having a pre-defined agenda and schedule provided a better balance between long discussions and mental refreshments, preventing the fatigue caused by endless discussions.</li> <li><strong>Action Points:</strong> Some participants recommended explicitly asking for action points at the end of each session and assigning people to follow-up tasks.</li> <li><strong>Remote Participation:</strong> Remote attendees appreciated the inclusive setup and opportunities to actively participate in discussions.</li> <li><strong>Technical Challenges:</strong> There were bandwidth and video streaming issues during some sessions due to the large number of participants.</li> </ul> <p><a href="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-feedback.jpg" title="Hackfest main room: laptop screen displays remote participants"><img src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-feedback.jpg" alt="" /></a></p> <h2 id="thank-you-for-joining-the-2024-display-next-hackfest">Thank you for joining the 2024 Display Next Hackfest</h2> <p>We can’t help but thank the 40 participants, who engaged in-person or virtually on relevant discussions, for a collaborative evolution of the Linux display stack and for building an insightful agenda.</p> <p>A big thank you to the leaders and presenters of the nine sessions: Christopher Cameron (Google), Harry Wentland (AMD), Leo Li (AMD), Mario Limoncello (AMD), Sebastian Wick (RedHat) and Xaver Hugl (KDE/BlueSystems) for the effort in preparing the sessions, explaining the topic and guiding discussions. My acknowledge to the others in-person participants that made such an effort to travel to A Coruña: Alex Goins (NVIDIA), David Turner (Raspberry Pi), Georges Stavracas (Igalia), Joan Torres (SUSE), Liviu Dudau (Arm), Louis Chauvet (Bootlin), Robert Mader (Collabora), Tian Mengge (GravityXR), Victor Jaquez (Igalia) and Victoria Brekenfeld (System76). It was and awesome opportunity to meet you and chat face-to-face.</p> <p>Finally, thanks virtual participants who couldn’t make it in person but organized their days to actively participate in each discussion, adding different perspectives and valuable inputs even remotely: Abhinav Kumar (Qualcomm), Chaitanya Borah (Intel), Christopher Braga (Qualcomm), Dor Askayo, Jiri Koten (RedHat), Jonas Ådahl (Red Hat), Leandro Ribeiro (Collabora), Marti Maria (Little CMS), Marijn Suijten, Mario Kleiner, Martin Stransky (Red Hat), Michel Dänzer (Red Hat), Miguel Casas-Sanchez (Google), Mitulkumar Golani (Intel), Naveen Kumar (Intel), Niels De Graef (Red Hat), Pekka Paalanen (Collabora), Pichika Uday Kiran (AMD), Shashank Sharma (AMD), Sriharsha PV (AMD), Simon Ser, Uma Shankar (Intel) and Vikas Korjani (AMD).</p> <p>We look forward to another successful Display Next hackfest, continuing to drive innovation and improvement in the Linux display ecosystem!</p> Wed, 25 Sep 2024 14:50:00 +0100 https://melissawen.github.io/blog/2024/09/25/reflections-2024-display-next-hackfest https://melissawen.github.io/blog/2024/09/25/reflections-2024-display-next-hackfest