14 Feb 2025

feedPlanet GNOME

Andy Wingo: tracepoints: gnarly but worth it

Hey all, quick post today to mention that I added tracing support to the Whippet GC library. If the support library for LTTng is available when Whippet is compiled, Whippet embedders can visualize the GC process. Like this!

Screenshot of perfetto showing a generational PCC trace

Click above for a full-scale screenshot of the Perfetto trace explorer processing the nboyer microbenchmark with the parallel copying collector on a 2.5x heap. Of course no image will have all the information; the nice thing about trace visualizers like is that you can zoom in to sub-microsecond spans to see exactly what is happening, have nice mouseovers and clicky-clickies. Fun times!

on adding tracepoints

Adding tracepoints to a library is not too hard in the end. You need to pull in the lttng-ust library, which has a pkg-config file. You need to declare your tracepoints in one of your header files. Then you have a minimal C file that includes the header, to generate the code needed to emit tracepoints.

Annoyingly, this header file you write needs to be in one of the -I directories; it can't be just in the the source directory, because lttng includes it seven times (!!) using computed includes (!!!) and because the LTTng file header that does all the computed including isn't in your directory, GCC won't find it. It's pretty ugly. Ugliest part, I would say. But, grit your teeth, because it's worth it.

Finally you pepper your source with tracepoints, which probably you wrap in some macro so that you don't have to require LTTng, and so you can switch to other tracepoint libraries, and so on.

using the thing

I wrote up a little guide for Whippet users about how to actually get traces. It's not as easy as perf record, which I think is an error. Another ugly point. Buck up, though, you are so close to graphs!

By which I mean, so close to having to write a Python script to make graphs! Because LTTng writes its logs in so-called Common Trace Format, which as you might guess is not very common. I have a colleague who swears by it, that for him it is the lowest-overhead system, and indeed in my case it has no measurable overhead when trace data is not being collected, but his group uses custom scripts to convert the CTF data that he collects to... GTKWave (?!?!?!!).

In my case I wanted to use Perfetto's UI, so I found a script to convert from CTF to the JSON-based tracing format that Chrome profiling used to use. But, it uses an old version of Babeltrace that wasn't available on my system, so I had to write a new script (!!?!?!?!!), probably the most Python I have written in the last 20 years.

is it worth it?

Yes. God I love blinkenlights. As long as it's low-maintenance going forward, I am satisfied with the tradeoffs. Even the fact that I had to write a script to process the logs isn't so bad, because it let me get nice nested events, which most stock tracing tools don't allow you to do.

I fixed a small performance bug because of it - a worker thread was spinning waiting for a pool to terminate instead of helping out. A win, and one that never would have shown up on a sampling profiler too. I suspect that as I add more tracepoints, more bugs will be found and fixed.

fin

I think the only thing that would be better is if tracepoints were a part of Linux system ABIs - that there would be header files to emit tracepoint metadata in all binaries, that you wouldn't have to link to any library, and the actual tracing tools would be intermediated by that ABI in such a way that you wouldn't depend on those tools at build-time or distribution-time. But until then, I will take what I can get. Happy tracing!

14 Feb 2025 1:32pm GMT

This Week in GNOME: #187 Triple Buffered Notifications

Update on what happened across the GNOME project in the week from February 07 to February 14.

GNOME Core Apps and Libraries

Mutter

A Wayland display server and X11 window manager and compositor library.

Georges Stavracas (feaneron) announces

Today, just in time for this edition of This Week in GNOME and after 5 years, more than a thousand review comments, and multiple massive refactorings and rewrites, the legendary merge request mutter!1441 was merged.

This merge requests introduces an additional render buffer when Mutter is not able to keep up with the frames.

The technique commonly known as dynamic triple buffering can help in situations where the total time to generate a frame - including CPU and GPU work - is longer than one refresh cycle. This improves the concurrency capabilities of Mutter by letting the compositor start working on the next frame as early as possible, even when the previous frame isn't displayed.

In practice, this kind of situation can happen with sudden burst of activity in the compositor. For example, when the GNOME Shell overview is opened after a period of low activity.

This should improve the perceived smoothness of GNOME, with less skipped frames and more fluid animations.

GNOME Shell

Core system user interface for things like launching apps, switching windows, system search, and more.

Julian Sparber (Away till Jan 7th) reports

The long awaited notification grouping was merged this week into GNOME Shell, just in time for GNOME 48. This was a huge effort by multiple parties, especially by Florian Müllner who spend countless hours reviewing code changes. This is probably one of the most visible features added to GNOME thanks to the STF grant.

GNOME Contacts

Keep and organize your contacts information.

Adrien Plazas announces

Contacts received some small last minute changes right in time for GNOME 48:

  • its contact editor's spacing have been overhauled to match other GNOME apps,
  • its birthday editing row and dialog got redesigned to not only look better but work better on mobile as well.

GNOME Circle Apps and Libraries

Tobias Bernard announces

This week Drum Machine was accepted into Circle! It's a delightful little app to play with drum patterns and prototype track ideas. Congratulations!

Third Party Projects

Krafting - Vincent reports

SemantiK got two releases last week: 1.4.0 and 1.5.0. They both bring new improvements, code refactoring, more translation work (thanks to @johnpetersa19 for the Brazilian Portuguese translation), and a revamped language selector!

The next big step would be to create more Language Pack, if you want to help with that, feel free to contact me via Matrix!

Krafting - Vincent reports

Also, last week, I've been hard at work fixing bugs throughout all my apps, and making them fully responsive on small screens, making them perfect for Mobile Linux ! 🎉📱

Hex Colordle got some bug fixes and small improvements to message when you lose.

Playlifin Voyager and PedantiK got some UI tweaks and bug fixes

Reddy got some better image scaling, making it way better on small screens, as well as some library version bumps.

Gir.Core

Gir.Core is a project which aims to provide C# bindings for different GObject based libraries.

Marcel Tiede says

GirCore verion 0.6.2 was released. It features support for .NET 9 and modernized the internal binding code resulting in better garbage collector integration and the removal of reflection based code. As a result there are several breaking changes. A new beginner friendly tutorial was contributed and can be found on the homepage. Please see the release notes for more details.

Fractal

Matrix messaging app for GNOME written in Rust.

Kévin Commaille announces

Due to a couple of unfortunate but important regressions in Fractal 10, we are releasing Fractal 10.1 so our users don't have to wait too long for them to be addressed. This minor version fixes the following issues:

  • Some rooms were stuck in an unread state, even after reading them or marking them as read.
  • Joining or creating a room would crash the app.

This version is available right now on Flathub.

If you want to help us avoid regressions like that in the future, you could use Fractal Nightly! Or even better, you could pick up one of our issues and become part of the problem solution.

Events

Kristi Progri announces

GUADEC 2025 Call for Papers is officially open! Submit your paper by March 16th via this link: https://events.gnome.org/event/259/abstracts/#submit-abstract

That's all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

14 Feb 2025 12:00am GMT

13 Feb 2025

feedPlanet GNOME

Cassidy James Blaede: GNOME Should Kick the Foot to the Curb… Mostly

This past week volunteers working with the GNOME design and engagement teams debuted a brand new GNOME.org website-one that was met largely with one of two reactions:

  1. It's beautiful and modern, nice work! and

  2. Where is the foot‽

You see, the site didn't[^logo update] feature the GNOME logo at the top of the page-it just had the word GNOME, with the actual logo relegated to the footer. Admittedly, some folks reacted both ways (it's pretty, but where's the foot?). To me, it seems that the latter reaction was mostly the sentiment of a handful of long-time contributors who have understandably grown very cozy with the current GNOME logo:

GNOME Logo, which is a foot GNOME Logo, which is a foot (dark version)

[^logo update]: 2024-02-14: I wrote a quick merge request to use the logo on the website yesterday since I figured someone else would, anyway. I wanted to demonstrate what it would look like (and do it "right" if it was going to happen). That change has since been merged.

Why the foot?

The current GNOME logo is a four-toed foot that is sort of supposed to look like a letter G. According to legend (read: my conversations with designers and contributors who have been working with GNOME for more years than I have fingers and toes), it is basically a story of happenstance: an early wallpaper featured footprints in the sand, that was modified into an icon for the menu, that was turned into a sort of logo while being modified to look like the letter G, and then that version was flattened and cleaned up a bit and successfully trademarked by the GNOME Foundation.

Evolution of the logo, 1997–2002

Graphic shared by Michael Downey on Mastodon

So, why do people like it? My understanding (and please drop a comment if I'm wrong) is that it often boils down to one or more of:

  1. It's always been this way; as long as GNOME has had an official logo, it's been a variation of the foot.

  2. It's a trademark so it's not feasible to change it from a legal or financial perspective.

  3. It has personality, and anything new would run the risk of being bland.

  4. It has wide recognition at least within the open source enthusiast and developer space, so changing it would be detrimental to the brand equity.

What's the problem?

I'm the first to admit that I don't find the foot to be a particularly good logo. Over time, I've narrowed down my thoughts (and the feedback I've heard from others) into a few recurring reasons:

  1. It doesn't convey anything about the name or project which by itself may be fine-many logos don't directly. But it feels odd to have such a bold logo choice that doesn't directly related to the name "GNOME," or to any specific aspect of the project.

  2. It's an awkward shape that doesn't fit cleanly into a square or circle, especially at smaller sizes (e.g. for a social media avatar or favicon). It's much taller than it is wide, and it's lopsided weight-wise. This leads to frustrations from designers when trying to fit the logo into a square or circle space, leading to excessive amounts of whitespace and/or error-prone manual alignment compared to other elements.

  3. It is actively off-putting and unappealing to at least some folks including much of the GNOME design team, newer contributors, people outside the open source bubble-and apparently potentially entire cultures (which has been raised multiple times over the past 20+ years). Anecdotally, almost everyone new I've introduced GNOME to has turned their nose up at the "weird foot," whether it's when showing the website or rocking a tee or sticker to support the project. It doesn't exactly set a great first impression for a community and modern computing platform. And yes, there are a bunch of dumb memes out there about GNOME devs all being foot fetishists which-while I'm not one to shame what people are into-is not exactly the brand image you want for your global, inclusive open source project.

  4. It raises the question of what the role of the design team is: if the design team cannot be allowed to effectively lead the design of the project, what are we even doing? I think this is why the topic feels so existential to me as a member of the design team. User experience design includes the moment someone first interacts with the brand of a product through them actually using it day-to-day-and right now, the design team's hands are tied for the first half of that journey.

Issues with the foot Issues with the foot (dark)

The imbalance and complexity make for non-ideal situations

So what can we do?

While there are some folks that would push for a complete rebrand of GNOME-name included, I feel like there's a softer approach we could take to the issue. I would also point out that the vast majority of people using GNOME-those on Ubuntu, RHEL, Fedora, Endless OS, Debian, etc.-are not seeing the foot anywhere. They're seeing their distro's logo, and for many, are using using e.g. "Ubuntu" and may not even be aware they're using GNOME.

Given all of the above, I propose that a path forward would be to:

  1. Phase the foot out from any remaining user-facing spaces since it's hard to work with in all of the contexts we need to use a logo, and it's not particularly attractive to new users or welcoming to potential contributors-something we need to keep in mind as an aging open source project. This has been an unspoken natural phenomenon as members of the GNOME design team have soured a bit on trying to make designs look nice while accommodating the foot; as a result we have started to see less prominent usage of the foot e.g. on release notes, GNOME Circle, This Week in GNOME, the GNOME Handbook, the new website (before it was re-added), and in other spaces where the people doing the design work aren't the most fond of it.

  2. Commission a new brand logo to represent GNOME to the outside world; this would be the logo you'd expect to see at GNOME.org, on user-facing social media profiles, on event banners, on merch, etc. We've been mulling ideas over in the design team for literal years at this point, but it's been difficult to pursue anything seriously without attracting very loud negative feedback from a handful of folks-perhaps if it is part of a longer-term plan explicitly including the above steps, it could be something we'd be able to pursue. And it could still be something quirky, cute, and whimsical! I personally don't love the idea of something super generic as a logo-I think something that connects to "gnomes," our history, and/or our modern illustration style would be great here. But importantly, it would need to be designed with the intent of its modern usage in mind, e.g. working well at small sizes, in social media avatars, etc.

  3. Refresh the official GNOME brand guidelines by explicitly including our modern use of color, animation, illustrations, and recurring motifs (like the amazing wallpapers from Jakub!). This is something that has sort of started happening naturally, e.g. with the web team's newer web designs and as the design team made the decision to move to Inter-based Adwaita Sans for the user interface-and this push continues to receive positive feedback from the community. But much of these efforts have not been reflected in the official project brand guidelines, causing an awkward disconnect between what we say the brand is and how it's actually widely used and perceived.

  4. Immortalize the foot as a mascot, something to be used in developer documentation, as an easter egg, and perhaps in contributor-facing spaces. It's much easier to tell newcomers, "oh this is a goofy icon that used to be our logo-we love it, even if it's kind of silly" without it having to represent the whole project from the outside. It remains a symbol for those "in the know" within the contributor community while avoiding it necessarily representing the entire GNOME brand.

  5. Stretch goal: title-case Gnome as a brand name. We've long moved past GNOME being an acronym (GNU Network Object Model Environment?)-with a bit of a soft rebrand, I feel we could officially say that it's spelled "Gnome," especially if done so in an official logotype. As we know, much like the pronunciation of GNOME itself, folks will do what they want-and they're free to!-but this would be more about how the brand name is used/styled in an official capacity. I don't feel super strongly about this one, but it is awkward to have to explain why it's called GNOME and all caps but not actually an acronym but it used to be-and why the logo is a foot-any time I tell someone what I contribute to. ;)

What do you think?

I genuinely think GNOME as a project and community is in a good place to move forward with modernizing our outward image a bit. Members of the design team like Jamie, kramo, Brage, Jakub, Tobias, Sam, and Allan and other contributors across the project like Alice, Sophie, and probably half a dozen more I am forgetting have been working hard at modernizing our UI and image when it comes to software-I think it's time we caught up with the outward brand itself.

Hit me up on Mastodon or any of the links in the footer to tell me if you think I'm right, or if I've gotten this all terribly wrong. :)

13 Feb 2025 12:00am GMT

03 Feb 2025

feedplanet.freedesktop.org

Christian Schaller: Looking ahead at 2025 and Fedora Workstation and jobs on offer!

So a we are a little bit into the new year I hope everybody had a great break and a good start of 2025. Personally I had a blast having gotten the kids an air hockey table as a Yuletide present :). Anyway, wanted to put this blog post together talking about what we are looking at for the new year and to let you all know that we are hiring.

Artificial Intelligence
One big item on our list for the year is looking at ways Fedora Workstation can make use of artificial intelligence. Thanks to IBMs Granite effort we know have an AI engine that is available under proper open source licensing terms and which can be extended for many different usecases. Also the IBM Granite team has an aggressive plan for releasing updated versions of Granite, incorporating new features of special interest to developers, like making Granite a great engine to power IDEs and similar tools. We been brainstorming various ideas in the team for how we can make use of AI to provide improved or new features to users of GNOME and Fedora Workstation. This includes making sure Fedora Workstation users have access to great tools like RamaLama, that we make sure setting up accelerated AI inside Toolbx is simple, that we offer a good Code Assistant based on Granite and that we come up with other cool integration points.

Wayland
The Wayland community had some challenges last year with frustrations boiling over a few times due to new protocol development taking a long time. Some of it was simply the challenge of finding enough people across multiple projects having the time to follow up and help review while other parts are genuine disagreements of what kind of things should be Wayland protocols or not. That said I think that problem has been somewhat resolved with a general understanding now that we have the 'ext' namespace for a reason, to allow people to have a space to review and make protocols without an expectation that they will be universally implemented. This allows for protocols of interest only to a subset of the community going into 'ext' and thus allowing protocols that might not be of interest to GNOME and KDE for instance to still have a place to live.

The other more practical problem is that of having people available to help review protocols or providing reference implementations. In a space like Wayland where you need multiple people from multiple different projects it can be hard at times to get enough people involved at any given time to move things forward, as different projects have different priorities and of course the developers involved might be busy elsewhere. One thing we have done to try to help out there is to set up a small internal team, lead by Jonas Ådahl, to discuss in-progress Wayland protocols and assign people the responsibility to follow up on those protocols we have an interest in. This has been helpful both as a way for us to develop internal consensus on the best way forward, but also I think our contribution upstream has become more efficient due to this.

All that said I also believe Wayland protocols will fade a bit into the background going forward. We are currently at the last stage of a community 'ramp up' on Wayland and thus there is a lot of focus on it, but once we are over that phase we will probably see what we saw with X.org extensions over time, that for the most time new extensions are so niche that 95% of the community don't pay attention or care. There will always be some new technology creating the need for important new protocols, but those are likely to come along a relatively slow cadence.

High Dynamic Range

HDR support in GNOME Control Center

HDR support in GNOME Control Center

As for concrete Wayland protocols the single biggest thing for us for a long while now has of course been the HDR support for Linux. And it was great to see the HDR protocol get merged just before the holidays. I also want to give a shout out to Xaver Hugl from the KWin project. As we where working to ramp up HDR support in both GNOME Shell and GTK+ we ended up working with Xaver and using Kwin for testing especially the GTK+ implementation. Xaver was very friendly and collaborative and I think HDR support in both GNOME and KDE is more solid thanks to that collaboration, so thank you Xaver!

Talking about concrete progress on HDR support Jonas Adahl submitted merge requests for HDR UI controls for GNOME Control Center. This means you will be able to configure the use of HDR on your system in the next Fedora Workstation release.

PipeWire
I been sharing a lot of cool PipeWire news here in the last couple of years, but things might slow down a little as we go forward just because all the major features are basically working well now. The PulseAudio support is working well and we get very few bug reports now against it. The reports we are getting from the pro-audio community is that PipeWire works just as well or better as JACK for most people in terms of for instance latency, and when we do see issues with pro-audio it tends to be more often caused by driver issues triggered by PipeWire trying to use the device in ways that JACK didn't. We been resolving those by adding more and more options to hardcode certain options in PipeWire, so that just as with JACK you can force PipeWire to not try things the driver has problems with. Of course fixing the drivers would be the best outcome, but for some of these pro-audio cards they are so niche that it is hard to find developers who wants to work on them or who has hardware to test with.

We are still maturing the video support although even that is getting very solid now. The screen capture support is considered fully mature, but the camera support is still a bit of a work in progress, partially because we are going to a generational change the camera landscape with UVC cameras being supplanted by MIPI cameras. Resolving that generational change isn't just on PipeWire of course, but it does make the a more volatile landscape to mature something in. Of course an advantage here is that applications using PipeWire can easily switch between V4L2 UVC cameras and libcamera MIPI cameras, thus helping users have a smooth experience through this transition period.
But even with the challenges posed by this we are moving rapidly forward with Firefox PipeWire camera support being on by default in Fedora now, Chrome coming along quickly and OBS Studio having PipeWire support for some time already. And last but not least SDL3 is now out with PipeWire camera support.

MIPI camera support
Hans de Goede, Milan Zamazal and Kate Hsuan keeps working on making sure MIPI cameras work under Linux. MIPI cameras are a step forward in terms of technical capabilities, but at the moment a bit of a step backward in terms of open source as a lot of vendors believe they have 'secret sauce' in the MIPI camera stacks. Our works focuses mostly on getting the Intel MIPI stack fully working under Linux with the Lattice MIPI aggregator being the biggest hurdle currently for some laptops. Luckily Alan Stern, the USB kernel maintainer, is looking at this now as he got the hardware himself.

Flatpak
Some major improvements to the Flatpak stack has happened recently with the USB portal merged upstream. The USB portal came out of the Sovereign fund funding for GNOME and it gives us a more secure way to give sandboxed applications access to you USB devcices. In a somewhat related note we are still working on making system daemons installable through Flatpak, with the usecase being applications that has a system daemon to communicate with a specific piece of hardware for example (usually through USB). Christian Hergert got this on his todo list, but we are at the moment waiting for Lennart Poettering to merge some pre-requisite work into systemd that we want to base this on.

Accessibility
We are putting in a lot of effort towards accessibility these days. This includes working on portals and Wayland extensions to help facilitate accessibility, working on the ORCA screen reader and its dependencies to ensure it works great under Wayland. Working on GTK4 to ensure we got top notch accessibility support in the toolkit and more.

GNOME Software
Last year Milan Crha landed the support for signing the NVIDIA driver for use on secure boot. The main feature Milan he is looking at now is getting support for DNF5 into GNOME Software. Doing this will resolve one of the longest standing annoyances we had, which is that the dnf command line and GNOME Software would maintain two separate package caches. Once the DNF5 transition is done that should be a thing of the past and thus less risk of disk space being wasted on an extra set of cached packages.

Firefox
Martin Stransky and Jan Horak has been working hard at making Firefox ready for the future, with a lot of work going into making sure it supports the portals needed to function as a flatpak and by bringing HDR support to Firefox. In fact Martin just got his HDR patches for Firefox merged this week. So with the PipeWire camera support, Flatpak support and HDR support in place, Firefox will be ready for the future.

We are hiring! looking for 2 talented developers to join the Red Hat desktop team
We are hiring! So we got 2 job openings on the Red Hat desktop team! So if you are interested in joining us in pushing the boundaries of desktop linux forward please take a look and apply. For these 2 positions we are open to remote workers across the globe and while the job adds list specific seniorities we are somewhat flexible on that front too for the right candidate. So be sure to check out the two job listings and get your application in! If you ever wanted to work fulltime on GNOME and related technologies this is your chance.

03 Feb 2025 12:29pm GMT

20 Jan 2025

feedplanet.freedesktop.org

André Almeida: Linux 6.13, I WANT A GUITAR PEDAL

Just as 2025 is starting, we got a new Linux release in mid January, tagged as 6.13. In the spirit of holidays, Linus Torvalds even announced during 6.13-rc6 that he would be building and raffling a guitar pedal for a random kernel developer!

As usual, this release comes with a pack of exciting news done by the kernel community:

To know more about the community improvements, check out the summary made by Kernel Newbies.

Now let's highlight the contributions made by Igalians for this release.

Case-insensitive support for tmpfs

Case sensitivity has been a traditional difference between Linux distros and MS Windows, with the most popular filesystems been in opposite sides: while ext4 is case sensitive, NTFS is case insensitive. This difference proved to be challenging when Windows apps, mainly games, started to be a common use case for Linux distros (thanks to Wine!). For instance, games running through Steam's Proton would expect that the path assets/player.png and assets/PLAYER.PNG would point to be the same file, but this is not the case in ext4. To avoid doing workarounds in userspace, ext4 has support for casefolding since Linux 5.2.

Now, tmpfs joins the group of filesystems with case-insensitive support. This is particularly useful for running games inside containers, like the combination of Wine + Flatpak. In such scenarios, the container shares a subset of the host filesystem with the application, mounting it using tmpfs. To keep the filesystem consistent, with the same expectations of the host filesystem about the mounted one, if the host filesystem is case-insensitive we can do the same thing for the container filesystem too. You can read more about the use case in the patchset cover letter.

While the container frameworks implement proper support for this feature, you can play with it and try it yourself:

$ mount -t tmpfs -o casefold fs_name /mytmpfs
$ cd /mytmpfs # case-sensitive by default, we still need to enable it
$ mkdir a
$ touch a; touch A
$ ls
A  a
$ mkdir B; cd b
cd: The directory 'b' does not exist
$ # now let's create a case-insensitive dir
$ mkdir case_dir
$ chattr +F case_dir
$ cd case_dir
$ touch a; touch A
$ ls
a
$ mkdir B; cd b
$ pwd
$ /home/user/mytmpfs/case_dir/B

V3D Super Pages support

As part of Igalia's effort for enhancing the graphics stack for Raspberry Pi, the V3D DRM driver now has support for Super Pages, improving performance and making memory usage more efficient for Raspberry Pi 4 and 5. Using Linux 6.13, the driver will enable the MMU to allocate not only the default 4KB pages, but also 64KB "Big Pages" and 1MB "Super Pages".

To measure the difference that Super Pages made to the performance, a series of benchmarks where used, and the highlights are:

You can read a detailed post about this, with all benchmark results, in Maíra's blog post, including a super cool PlayStation 2 emulation showcase!

New transparent_hugepage_shmem= command-line parameter

Igalia contributed new kernel command-line parameters to improve the configuration of multi-size Transparent Huge Pages (mTHP) for shmem. These parameters, transparent_hugepage_shmem= and thp_shmem=, enable more flexible and fine-grained control over the allocation of huge pages when using shmem.

The transparent_hugepage_shmem= parameter allows users to set a global default huge page allocation policy for the internal shmem mount. This is particularly valuable for DRM GPU drivers. Just as CPU architectures, GPUs can also take advantage of huge pages, but this is possible only if DRM GEM objects are backed by huge pages.

Since GEM uses shmem to allocate anonymous pageable memory, having control over the default huge page allocation policy allows for the exploration of huge pages use on GPUs that rely on GEM objects backed by shmem.

In addition, the thp_shmem= parameter provides fine-grained control over the default huge page allocation policy for specific huge page sizes.

By configuring page sizes and policies of huge-page allocations for the internal shmem mount, these changes complement the V3D Super Pages feature, as we can now tailor the size of the huge pages to the needs of our GPUs.

DRM and AMDGPU improvements

As usual in Linux releases, this one collects a list of improvements made by our team in DRM and AMDGPU driver from the last cycle.

Cosmic (the desktop environment behind Pop! OS) users discovered some bugs in the AMD display driver regarding the handling of overlay planes. These issues were pre-existing and came to light with the introduction of cursor overlay mode. They were causing page faults and divide errors. We debugged the issue together with reporters and proposed a set of solutions that were ultimately accepted by AMD developers in time for this release.

In addition, we worked with AMD developers to migrate the driver-specific handling of EDID data to the DRM common code, using drm_edid opaque objects to avoid handling raw EDID data. The first phase was incorporated and allowed the inclusion of new functionality to get EDID from ACPI. However, some dependencies between the AMD the Linux-dependent and OS-agnostic components were left to be resolved in next iterations. It means that next steps will focus on removing the legacy way of handling this data.

Also in the AMD driver, we fixed one out of bounds memory write, fixed one warning on a boot regression and exposed special GPU memory pools via the fdinfo common DRM framework.

In the DRM scheduler code, we added some missing locking, removed a couple of re-lock cycles for slightly reduced command submission overheads and clarified the internal documentation.

In the common dma-fence code, we fixed one memory leak on the failure path and one significant runtime memory leak caused by incorrect merging of fences. The latter was found by the community and was manifesting itself as a system out of memory condition after a few hours of gameplay.

sched_ext

The sched_ext landed in kernel 6.12 to enable the efficient development of BPF-based custom schedulers. During the 6.13 development cycle, the sched_ext community has made efforts to harden the code to make it more reliable and clean up the BPF APIs and documentation for clarity.

Igalia has contributed to hardening the sched_ext core code. We fixed the incorrect use of the scheduler run queue lock, especially during initializing and finalizing the BPF scheduler. Also, we fixed the missing RCU lock protections when the sched_core selects a proper CPU for a task. Without these fixes, the sched_ext core, in the worst case, could crash or raise a kernel oops message.

Other Contributions & Fixes

syzkaller, a kernel fuzzer, has been an important instrument to find kernel bugs. With the help of KASAN, a memory error detector, and syzbot, numerous such bugs have been reported and fixed.

Igalians have contributed to such fixes around a lot of subsystems (like media, network, etc), helping reduce the number of open bugs.

Check the complete list of Igalia's contributions for the 6.13 release

Authored (70)

André Almeida

Changwoo Min

Christian Gmeiner

Guilherme G. Piccoli

Maíra Canal

Melissa Wen

Thadeu Lima de Souza Cascardo

Tvrtko Ursulin

Reviewed (41)

André Almeida

Christian Gmeiner

Iago Toral Quiroga

Jose Maria Casanova Crespo

Juan A. Suarez

Maíra Canal

Tvrtko Ursulin

Tested (1)

Christian Gmeiner

Acked (5)

Changwoo Min

Maíra Canal

Maintainer SoB (6)

Maíra Canal

20 Jan 2025 12:00am GMT

18 Jan 2025

feedplanet.freedesktop.org

Simon Ser: Status update, January 2025

Hi all!

FOSDEM is approaching rapidly! I'll be there and will give a talk about modern IRC.

In wlroots land, we've finally merged support for the next-generation screen capture protocols, ext-image-capture-source-v1 and ext-image-copy-capture-v1! Compared to the previous wlroots-specific protocol, the new one provides better damage tracking, enables cursor capture (useful for remote desktop apps) and per-window capture (this part is not yet implemented in wlroots). Thanks to Kirill Primak, wlroots now supports the xdg-toplevel-icon-v1 protocol, useful for clients which want to update their window icon without changing their application ID (either by providing an icon name or pixel buffers). Kirill also added safety assertions everywhere in wlroots to ensure that all listeners are properly removed when a struct is destroyed.

I've revived some old patches to better identify outputs in wlroots and libdisplay-info. Currently, there are two common ways to refer to an output: either by its name (e.g. "DP-2"), or by its make+model+serial (e.g. "Foo Corp C4FE 42424242"). Unfortunately, both of these naming schemes have downsides. The name is ill-suited to configuration files because it's unstable and might change on reboot or unplug (it depends on driver load order, and DP-MST connectors get a new name each time they are re-plugged). The make+model+serial uses a database to look up the human-readable manufacturer name (so database updates break config files), and is not unique enough (different models might share a duplicate string). A new wlr_output.port field and a libdisplay-info device tag should address these shortcomings.

Jacob McNamee has contributed a Sway patch to add security context properties to IPC, criteria and title format. With this patch, scripts can now figure out whether an application is sandboxed, and a special title can be set for sandboxed (or unsandboxed) apps. There are probably more use-cases we didn't think of!

I've managed to put aside some time to start reviewing the DRM color pipeline patches. As discussed in the last XDC it's in a pretty good shape so I've started dropping some Reviewed-by tags. While discussing with David Turner about libliftoff, I've realized that the DRM_MODE_PAGE_FLIP_EVENT flag was missing some documentation (it's not obvious how it interacts with the atomic uAPI) so I've sent a patch to fix that.

I continue pushing small updates to go-imap, bringing it little by little closer to version 2.0. I've added helpers to make it easier for servers to implement the FETCH command, implemented FETCH BINARY and header field decoding for SEARCH in the built-in in-memory server, added limits for the IMAP command size to prevent denial-of-service, and fixed a few bugs. While testing with ImapTest, I've discovered and fixed a bug in Go's mime/quotedprintable package.

Thanks to pounce, goguma now internally keeps track of message reactions. This is not used just yet, but will be soon once we add a user interface to display and send reactions. Support for deleting messages (called "redact" in the spec) has been merged. I've also implemented a small date indicator which shows up when scrolling in a conversation.

That's all for this month, see you at FOSDEM!

18 Jan 2025 10:00pm GMT