You want background playback? You get background playback! Shortwave 5.0 is now available and finally continues playback when you close the window, resolving the "most popular" issue on GitLab!

Shortwave uses the new Flatpak background portal for this, which means that the current playback status is now also displayed in the "Background Apps" menu.

The recording feature has also been overhauled. I have addressed a lot of user feedback here, e.g. you can now choose between 3 different modes:

• Save All Tracks: Automatically save all recorded tracks
• Decide for Each Track: Temporarily record tracks and save only the ones you want
• Record Nothing: Stations are played without recording

In addition to that the directory for saving recorded tracks can be customized, and users can now configure the minimum and maximum duration of recordings.

There is a new dialog window with additional details and options for current or past played tracks. For example, you no longer need to worry about forgetting to save your favorite track when the recording is finished - you can now mark tracks directly during playback so that they are automatically saved when the recording is completed.

You don't even need to open Shortwave for this, thanks to the improved notifications you can decide directly when a new track gets played whether you want to save it or not.

Of course the release also includes the usual number of bug fixes and improvements. For example, the volume can now be changed using the keyboard shortcut.

Enjoy!

05 Feb 2025 1:52pm GMT

Qt for MCUs 2.8.2 LTS (Long-Term Support) has been released and is available for download. This patch release provides bug fixes and other improvements while maintaining source compatibility with Qt for MCUs 2.8. It does not add any new functionality.

05 Feb 2025 12:02pm GMT

Claude 3.5 Sonnet is the best LLM to write QML code when prompted in English. If you want to know why we reached this conclusion, keep reading.

05 Feb 2025 6:01am GMT

Ramon Miranda has published a new video on the Krita channel: Memilio Impasto Brushes! Who doesn't love a nice impasto effect!

05 Feb 2025 12:00am GMT

With apps made for different form factors, it can be hard to find what works for your specific device. For example, we know it can be a bit difficult to find great apps that are actually designed to be used on a mobile phone or tablet. To help solve this, we're introducing a new collection: On the Go.

As the premier source of apps for Linux, Flathub serves a wide range of people across a huge variety of hardware: from ultra powerful developer workstations to thin and light tablets; from handheld gaming consoles to a growing number of mobile phones. Generally any app on Flathub will work on a desktop or laptop with a large display, keyboard, and mouse or trackpad. However, devices with only touch input and smaller screen sizes have more constraints.

Revealing the App Ecosystem​

Using existing data and open standards, we're now highlighting apps on Flathub that report as being designed to work on these mobile form factors. This new On the Go collection uses existing device support data submitted by app developers in their MetaInfo, the same spec that is used to build those app's listings for Flathub and other app store clients. The collection is featured on the Flathub.org home page for all devices.

Many of these apps are adaptive across screen sizes and input methods; you might be surprised to know that your favorite app on your desktop will also work great on a Linux phone, tablet, or Steam Deck's touch screen. We aim to help reveal just how rich and well-rounded the app ecosystem already is for these devices-and to give app developers another place for their apps to shine and be discovered.

Developers: It's Up to You​

As of this writing there are over 150 apps in the collection, but we expect there are cases where app developers have not provided the requisite device support data.

If you're the creator of an app that should work well on mobile form factors but isn't featured in the collection, take a minute to double-check the documentation and your own apps's MetaInfo to ensure it's accurate. Device support data can also be used by native app store clients across form factors to determine what apps are displayed or how they are ranked, so it's a good idea to ensure it's up to date regardless of what your app supports.

05 Feb 2025 12:00am GMT

In the past I may have spoken critically on Truetype fonts and their usage in PDF files. Recently I have come to the conclusion that it may have been too harsh and that Truetype fonts are actually somewhat nice. Why? Because I have had to add support for CFF fonts to CapyPDF. This is a font format that comes from Adobe. It encodes textual PostScript drawing operations into binary bytecode. Wikipedia does not give dates, but it seems to have been developed in the late 80s - early 90s. The name CFF part is an abbeviation for "complicated font format".

Double-checks notes.

Compact font format. Yes, that is what I meant to write. Most people reading this have probably not ever even seen a CFF file so you might be asking why is supporting CFF fonts even a thing nowadays? It's all quite simple. Many of the Truetype (and especially OpenType) fonts you see are not actually Truetype fonts. Instead they are Transfontners, glyphs in disguise. It is entirely valid to have a Truetype font that is merely an envelope holding a CFF font. As an example the Noto CJK fonts are like this. Aggregation of different formats is common in font files, and the main reason OpenType fonts have like four different and mutually incompatible ways of specifying color emoji. None of the participating entities were willing to accept anyone else's format so the end result was to add all of them. If you want Asian language support, you have to dive into the bowels of the CFF rabid hole.

As most people probably do not have sufficient historical perspective, let's start by listing out some major computer science achievements that definitely existed when CFF was being designed.

• File format magic numbers
• Archive formats that specify both the offset and size of the elements within
• Archive formats that afford access to their data in O(number of items in the archive) rather than O(number of bytes in the file)
• Data compression

CFF chooses to not do any of this nonsense. It also does not believe in consistent offset types. Sometimes the offsets within data objects refer to other objects by their order in the index they are in. Sometimes they refer to number of bytes from the beginning of the file. Sometimes they refer to number of bytes from the beginning of the object the offset data is written in. Sometimes it refers to something else. One of the downsides of this is that while some of the data is neatly organized into index structures with specified offsets, a lot of it is just free floating in the file and needs the equivalent of three pointer dereferences to access.

Said offsets are stored with a variable width encoding like so:

This makes writing subset CFF font files a pain. In order to write an offset value at some location X, you first must serialize everything up to that point to know where the value would be written. To know the value to write you have to serialize the the entire font up to the point where that data is stored. Typically the data comes later in the file than its offset location. You know what that means? Yes, storing all these index locations and hotpatching them afterwards once you find out where the actual data pointed to ended up in. Be sure to compute your patching locations correctly lest you end up in lengthy debugging sessions where your subset font files do not render correctly. In fairness all of the incorrect writes were within the data array and thus 100% memory safe, and, really, isn't that the only thing that actually matters?

One of the main data structures in a CFF file is a font dictionary stored in, as the docs say, "key-value pairs". This is not true. The "key-value dictionary" is neither key-value nor is it a dictionary. The entries must come in a specific order (sometimes) so it is not a dictionary. The entries are not stored as key-value pairs but as value-key pairs. The more accurate description of "value-key somewhat ordered array" does lack some punch so it is understandable that they went with common terminology. The backwards ordering of elements to some people confusion bring might, but it perfect sense makes, as the designers of the format a long history with PostScript had. Unknown is whether some of them German were.

Anyhow, after staring directly into the morass of madness for a sufficient amount of time the following picture emerges.

Final words

The CFF specification document contains data needed to decipher CFF data streams in nice tabular format, which is easy to convert to an enum. Trying it fails with an error message saying that the file has prohibited copypasting. This is a bit rich coming from Adobe, whose current stance seems to be that they can take any document opened with their apps and use it for AI training. I'd like to conclude this blog post by sending the following message to the (assumed) middle manager who made the decision that publicly available specification documents should prohibit copypasting:

YOU GO IN THE CORNER AND THINK ABOUT WHAT YOU HAVE DONE! AND DON'T EVEN THINK ABOUT COMING BACK UNTIL YOU ARE READY TO APOLOGIZE TO EVERYONE FOR YOU ACTIONS!

04 Feb 2025 1:16pm GMT

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

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

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:

• This release has two important improvements for task scheduling: lazy preemption and proxy execution. The goal with lazy preemption is to find a better balance between throughput and response time. A secondary goal is being able to make it the preferred non-realtime scheduling policy for most cases. Tasks that really need a reschedule in a hurry will use the older TIF_NEED_RESCHED flag. A preliminary work for proxy execution was merged, which will let us avoid priority-inversion scenarios when using real time tasks with deadline scheduling, for use cases such as Android.

• New important Rust abstractions arrived, such as VFS data structures and interfaces, and also abstractions for misc devices.

• Lightweight guard pages: guard pages are used to raise a fatal signal when accessed. This feature had the drawback of having a heavy performance impact, but in this new release the flag MADV_GUARD_INSTALL was added for the madvise() syscall, offering a lightweight way to guard pages.

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:

• +8.36% of FPS boost for Warzone 2100 in RPi4
• +3.62% of FPS boost for Quake 2 in RPi5
• 10% time reduction for the Mesa CI job v3dv-rpi5-vk-full:arm64
• Aether SX2 emulator is more fluid to play

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

• unicode: Fix utf8_load() error path
• MAINTAINERS: Add Unicode tree
• scripts/kernel-doc: Fix build time warnings
• libfs: Create the helper function generic_ci_validate_strict_name()
• ext4: Use generic_ci_validate_strict_name helper
• unicode: Export latest available UTF-8 version number
• unicode: Recreate utf8_parse_version()
• libfs: Export generic_ci_ dentry functions
• tmpfs: Add casefold lookup support
• tmpfs: Add flag FS_CASEFOLD_FL support for tmpfs dirs
• tmpfs: Expose filesystem features via sysfs
• docs: tmpfs: Add casefold options
• libfs: Fix kernel-doc warning in generic_ci_validate_strict_name
• tmpfs: Fix type for sysfs' casefold attribute
• tmpfs: Initialize sysfs during tmpfs init

Changwoo Min

• sched_ext: Replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass()
• sched_ext: Clarify sched_ext_ops table for userland scheduler
• sched_ext: add a missing rcu_read_lock/unlock pair at scx_select_cpu_dfl()
• MAINTAINERS: add me as reviewer for sched_ext

Christian Gmeiner

• drm/v3d: Use v3d_perfmon_find()

Guilherme G. Piccoli

• Documentation: Improve crash_kexec_post_notifiers description
• wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures

Maíra Canal

• drm/v3d: Address race-condition in MMU flush
• drm/v3d: Flush the MMU before we supply more memory to the binner
• drm/v3d: Fix return if scheduler initialization fails
• drm/gem: Create a drm_gem_object_init_with_mnt() function
• drm/v3d: Introduce gemfs
• drm/gem: Create shmem GEM object in a given mountpoint
• drm/v3d: Reduce the alignment of the node allocation
• drm/v3d: Support Big/Super Pages when writing out PTEs
• drm/v3d: Use gemfs/THP in BO creation if available
• drm/v3d: Add modparam for turning off Big/Super Pages
• drm/v3d: Expose Super Pages capability
• drm/vc4: Use vc4_perfmon_find()
• MAINTAINERS: Add Maíra to VC4 reviewers
• mm: shmem: control THP support through the kernel command line
• mm: move get_order_from_str() to internal.h
• mm: shmem: override mTHP shmem default with a kernel parameter
• mm: huge_memory: use strscpy() instead of strcpy()
• drm/v3d: Enable Performance Counters before clearing them
• drm/v3d: Ensure job pointer is set to NULL after job completion

Melissa Wen

• drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid
• drm/amd/display: switch to setting physical address directly
• drm/amd/display: always call connector_update when parsing freesync_caps
• drm/amd/display: remove redundant freesync parser for DP
• drm/amd/display: add missing tracepoint event in DM atomic_commit_tail
• drm/amd/display: fix page fault due to max surface definition mismatch
• drm/amd/display: increase MAX_SURFACES to the value supported by hw
• drm/amd/display: fix divide error in DM plane scale calcs

Thadeu Lima de Souza Cascardo

• media: uvcvideo: Require entities to have a non-zero unique ID
• hfsplus: don't query the device logical block size multiple times
• Bluetooth: btmtk: avoid UAF in btmtk_process_coredump

Tvrtko Ursulin

• drm/v3d: Appease lockdep while updating GPU stats
• drm/sched: Add locking to drm_sched_entity_modify_sched
• Documentation/gpu: Document the situation with unqualified drm-memory-
• drm/amdgpu: Drop unused fence argument from amdgpu_vmid_grab_used
• drm/amdgpu: Use drm_print_memory_stats helper from fdinfo
• drm/amdgpu: Drop impossible condition from amdgpu_job_prepare_job
• drm/amdgpu: Remove the while loop from amdgpu_job_prepare_job
• drm/sched: Optimise drm_sched_entity_push_job
• drm/sched: Stop setting current entity in FIFO mode
• drm/sched: Re-order struct drm_sched_rq members for clarity
• drm/sched: Re-group and rename the entity run-queue lock
• drm/sched: Further optimise drm_sched_entity_push_job
• drm/amd/pm: Vangogh: Fix kernel memory out of bounds write
• drm/amdgpu: Stop reporting special chip memory pools as CPU memory in fdinfo
• drm/amdgpu: Expose special on chip memory pools in fdinfo
• dma-fence: Fix reference leak on fence merge failure path
• dma-fence: Use kernel's sort for merging fences
• workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker

Reviewed (41)

André Almeida

• futex: Use atomic64_inc_return() in get_inode_sequence_number()
• futex: Use atomic64_try_cmpxchg_relaxed() in get_inode_sequence_number()
• mm: shmem: use signed int for version handling in casefold option

Christian Gmeiner

• drm/vc4: Use vc4_perfmon_find()
• drm/etnaviv: Request pages from DMA32 zone on addressing_limited
• drm/etnaviv: Use unsigned type to count the number of pages
• drm/etnaviv: Use 'unsigned' type to count the number of pages
• drm/etnaviv: Drop the <linux/pm_runtime.h> header
• drm/etnaviv: Fix missing mutex_destroy()
• drm/etnaviv: hold GPU lock across perfmon sampling
• drm/etnaviv: assert GPU lock held in perfmon pipe_*_read functions
• drm/etnaviv: unconditionally enable debug registers
• drm/etnaviv: update hardware headers from rnndb
• drm/etnaviv: take current primitive into account when checking for hung GPU
• drm/etnaviv: always allocate 4K for kernel ringbuffers
• drm/etnaviv: flush shader L1 cache after user commandstream

Iago Toral Quiroga

• drm/v3d: Address race-condition in MMU flush
• drm/v3d: Flush the MMU before we supply more memory to the binner
• drm/v3d: Fix return if scheduler initialization fails
• drm/v3d: Introduce gemfs
• drm/v3d: Reduce the alignment of the node allocation
• drm/v3d: Expose Super Pages capability
• drm/v3d: Enable Performance Counters before clearing them

Jose Maria Casanova Crespo

• drm/v3d: Ensure job pointer is set to NULL after job completion

Juan A. Suarez

• drm/vc4: Use vc4_perfmon_find()

Maíra Canal

• drm/v3d: Use v3d_perfmon_find()
• drm/vc4: Run default client setup for all variants.
• drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load
• drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush
• drm/vc4: Correct generation check in vc4_hvs_lut_load
• drm/vkms: Drop unnecessary call to drm_crtc_cleanup()

Tvrtko Ursulin

• drm/gem: Create a drm_gem_object_init_with_mnt() function
• drm/gem: Create shmem GEM object in a given mountpoint
• drm/v3d: Support Big/Super Pages when writing out PTEs
• drm/v3d: Use gemfs/THP in BO creation if available
• drm/v3d: Add modparam for turning off Big/Super Pages
• drm: add DRM_SET_CLIENT_NAME ioctl
• drm: use drm_file client_name in fdinfo
• drm/amdgpu: make drm-memory-* report resident memory
• dma-buf: fix dma_fence_array_signaled v4
• dma-buf: Fix __dma_buf_debugfs_list_del argument for !CONFIG_DEBUG_FS

Tested (1)

Christian Gmeiner

• drm/etnaviv: Replace the '&pdev->dev' with 'dev'

Acked (5)

Changwoo Min

• sched_ext: Rename scx_bpf_dispatch[_vtime]() to scx_bpf_dsq_insert[_vtime]()
• sched_ext: Rename scx_bpf_consume() to scx_bpf_dsq_move_to_local()
• sched_ext: Rename scx_bpf_dispatch[_vtime]_from_dsq*() -> scx_bpf_dsq_move[_vtime]*()

Maíra Canal

• MAINTAINERS: remove myself as a VKMS maintainer
• MAINTAINERS: Add myself as VKMS Maintainer

Maintainer SoB (6)

Maíra Canal

• MAINTAINERS: remove myself as a VKMS maintainer
• MAINTAINERS: Add myself as VKMS Maintainer
• drm/vkms: Add documentation
• drm/vkms: Suppress context imbalance detected by sparse warning
• drm/vkms: Add missing check for CRTC initialization
• drm/v3d: Drop allocation of object without mountpoint

20 Jan 2025 12:00am GMT

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