My summer development happenings - COSMIC, my webserver, and maybe some Kernel Development?

Hey guys, it has been a while. I figured this is a good time for me to do a retrospective on my summer (development-wise).

If you ready my last blog, I traveled to Japan. That was fun, but when I got back it was time to work and develop again!

Work

Most of my development this summer has been for my job. We make vehicle displays (more accurately, the full assembly with an LCD paired with a PCB that runs Linux). It’s pretty fun work, but obviously since it’s my full-time job, it takes up most of my dev time.

cosmic-packaging improvements

For this section, it’s good to know some of Fedora’s release stack:

• Copr: Hosting site for RPM packages independent of Fedora’s upstream repos (think AUR)
• Pagure: Git forge that is used by Fedora’s package specs
• Koji: Fedora’s build system, takes requests to build and builds from the given pagure branch (branches correspond to Fedora versions)
• Bodhi: Fedora’s update system, takes builds from Koji, and collects them into updates that are tested and then released.

Fedora’s release stack is overengineered IMO

If you want to know more about how I do COSMIC releases, I made a post about that!

I’ve been improving my scripts that help me to do COSMIC releases in Fedora, and now I have my cosmic-packaging-new-release script modified to support looping through queueing builds, and querying Koji for the status of builds.

The workflow is now:

• New COSMIC tags are released
• I build the packages in a COPR to validate that the builds work
• I run the cosmic-packaging-automation script, which does the following:
  • Create a new side tag, for rawhide builds (rawhide builds get released automatically, but we don’t want that when all the packages rely on each other, so side tags let us release all of them at once)
  • Queue all the builds in Koji
  • Wait 10 minutes
  • Check on the build status in Koji, if any builds failed, or aren’t building or complete in the target version, loop back to the queueing step.
  • Once all builds are building or complete, wait for all the builds to complete
  • Submit an update request for all versions in Bodhi

Webserver stuff

I’ve done some work on my webserver as well, making things more maintainable for myself (and also some security things).

I have a private repository where I store my server configuration, and I used to have my secrets stored in the repo, which is massively insecure, but I just haven’t had time to work on fixing it. I finally had some time (and motivation) to work on it, and I used a git plugin to scrub the secret keys from my repository entirely! Even though the repo is never going to be public, this does make me feel a little more safe.

I also finally set up cloudflare’s proxy for my domain! In the past, I wasn’t able to figure it out with my residential Wi-Fi, and I just assumed they had it blocked somehow, but turning on strict TLS/SSL protection on Cloudflare ended up fixing the problem! I guess port 80 was blocked by my residential ISP (for good reason), and somehow Cloudflare was relying on that even though it should always be using HTTPS. Forcing the strict mode fixed it, and my webserver is now more secure :)

Linux Kernel Development 👀

NOTE: (I added an eye emoji, and uhh I don’t know if it is actually showing up, because my editor is only showing a square. Enjoy if so!)

Anyways, I am diving into kernel development for the first time! I have an itch to scratch, which is a common way people get started with kernel development.

My specific itch is that for my Lenovo Legion 16APH8 device, there is a spurious GPE that wakes up the discrete GPU less than 1 second after it goes into D3Cold. This makes the dGPU go from D0 -> D3Hot -> D3Cold -> D0 within the span of 1 second, and then the GPU stays in D0 for however long the timeout is set before it attempts to go to sleep again (this seems to vary between the nouveau and nvidia-open kernel modules, but the behavior is present on both).

I worked with Lyude Paul, a nouveau maintainer, to work through finding the correct way to fix the issue. The first fix was to simply mask the offending GPE (0x10) in nouveau with a DMI quirk table to match the target device, and that evolved to masking the GPE in the PCI subsystem, in drivers/pci/quirks.c.

From there, Lyude wondered if we should try to make the GPE discovery dynamic because the BIOS firmware could always change in the future to use a different GPE. It also could be potentially harmful if we masked that GPE without knowing for sure that GPE was the one we originally made the quirk for. In response to this, I made two branches - one that has some common-sense checks to make sure that the GPE we’re masking is not crucial to the system functioning, and the other more interesting branch, added the source GPE to the ACPI notify information that is sent out to consumers (including the PCI subsystem). Using that, we can dynamically identify the GPE that’s causing the spurious wakeup.

Neither of these patches ended up being the one though. Lyude worked on the issue more, and ended up with a quirk that disables wakeups on the parent PCI port of the dGPU altogether. We found through testing that there’s really no reason we need firmware wakeups on that port, and any time the dGPU needs to be woken up, it’s done through an ACPI_VIDEO request.

Thanks to Lyude for the patience and willingness to work through this issue with me! Her patchset is now in the kernel mailing list, and I hope it’ll be available for Linux 7.3!

P.S. this is the first patch I’ve been a Co-author on for the Linux kernel! I hope I can do more kernel development in the future :)

What I want to work on in the future

I feel like I end up being interested in a lot of different areas (see my software wishlist for some examples), but if I end up having more time, there’s lots of things that I’m currently interested in, based on itches I

• Mobile Linux: I’d love to find things to work on in the mobile linux space! I have a used OnePlus 6T that I play around with postmarketOS on from time to time. I use Plasma Mobile, and it’s pretty cool, but there are definitely pain points. Maybe I’ll start by just reporting bugs that I find, because working on the KDE stack is probably a lot of bringup work (for one, I’ll have to use C++ blech).

  I can also see myself just working on various apps that need better mobile Linux support that I like to use. Zed comes to mind, but they have a touch input support PR that got sidelines for the moment due to not being important enough to the Zed team at the moment (time for the second blech of the blog post) [Link]

  Another weird one is OpenRCT2, which has touch support, but it’s pretty messed up when you actually use a mobile phone.

• The Kernel: I already have one co-authored patch that’s in the mailing list, but I want to work on some extra enablement bits for my Lenovo Legion laptop. Due to the rising cost of tech prices, I imagine I’ll have my laptop for quite a while (I’ve already had it for over 2 years), so I want to make sure things like the keyboard LEDs can be controlled without having to rely on a userspace privileged process to control something that simple.

• More COSMIC: It has been a while since I did some COSMIC development, I might go back and try to finish up some of my old PRs. I don’t daily drive COSMIC, in part because the design at the moment leaves a lot to be desired, but I still really like Rust, and it’s nice to develop for.

AI Stuff

I put this section at the bottom because no one wants to hear about AI stuff at this point to be honest.

At work, we’ve been encouraged to use LLMs to get things done quicker, and at this point, I think I probably write about 5% of the work code I push in a day. I’m mostly using Claude Opus 5. I’m not sure how I feel about all the LLM hubbub, because while it’s exciting to get lots of things done, it feels like I’m losing control of the software I’m pushing out in a way. I no longer know all the ins and outs of my software. If I were co-writing the software I write for my company, then I imagine I’d already be feeling this way, but since it’s my brainchild, it just feels weird.

I’m also still doing my local LLM stuff, and so that’s been fun. I’m trying to keep a good balance of using LLMs and not letting my brain completely rot, but I’ll just have to keep everyone posted on what it’s like. I have lots of ideas on what I want to contribute to (some of those things will show up below), and I do think that using LLMs has helped with the investigation part of contributing; however, it’s definitely hard to not just take it to its logical conclusion (i.e. we have a patch that can be sent upstream). I need to take time to understand the projects I’m contributing to, and hand-write patches. I don’t want to lose the personal aspect to my development. Maybe I’ll write a blog post in the future talking about that struggle.

That’s all

Anyways, I’m kinda mentally crashed out this weekend, life has been busy, so this blog was made with a lot of jumping around. I’m not even done with the post and I’m writing this conclusion, soooooo bear with me.

If you made it this far, get stickbugged: