Week of June 10 – 14Pop!_OS is a Linux distribution by System76, a Linux-based desktop hardware OEM. It is based on Ubuntu, with many enhancements specific to our vision of the desktop, and provides an optimal platform for our hardware, which is thoroughly tested throughout each release. These weekly posts highlight the developments that have been made each week in Pop!_OS.
GNOME Shell: High CPU Usage w/ TopIcons Extension
I found a patch that was made for GNOME Shell 3.32.2 which fixes the high CPU usage experienced when using the TopIcons extension. When the extension is enabled, I noticed that it would consistently consume 60% of a core at all times. With this new patch from upstream backported to the version of GNOME Shell that we're using (3.32.1), CPU usage of the gnome-shell process remains at a low 1-2%. Hopefully Ubuntu will push the 3.32.2 release to disco soon, so that we don't have to maintain this patch anymore. It seems to be available for the eoan development branch as of this moment.
Two changes were made to our mutter packaging this week.
Reduce CPU Usage by 20% When Dragging Windows
Currently in testing to be released soon is a new performance optimization that can reduce CPU usage by 20% when dragging windows. This could help further improve the choppy window drag animations experienced on NVIDIA systems which are currently affected by a driver bug that causes Xorg CPU usage to drastically rise when moving an OpenGL-accelerated window. I will get this merged in the next week.
Remove Patch Worsening NVIDIA Window Drag Perf
One of the included patches was recently discovered to only provide a benefit to Wayland sessions, in exchange for worsening the aforementioned NVIDIA driver bug that causes Xorg CPU usage to rise when dragging OpenGL-accelerated windows. Therefore, it has been removed, and everyone who reported that Chrome and Electron windows were choppier than usual when dragging them should now see an improvement. This was that patch, which is now marked as a work in progress.
GTK Theme Improvements
The following changes were merged to the master branch this week:
- Fixed incorrect background color on backdrop labels in active list rows
- Fixed Gitg to use a monospace font in its text views
GTK Icon Theme
A fix for the icon theme occurred during this week, which now uses more compliant menu icons.
ECS Disk Manager
During this week, a lot of progress was made on the ecs-disk-manager project, which began in the prior week. The main focus of this week was to implement the Rust bindings and wrappers necessary to retrieve all of the information about block devices on the system, whether they are physical block devices, or mapped devices. To that end, Rust bindings for
lvmdbus1were created. Once the bindings are developed, the task was then to design a disk prober that can fetch all the data from these sources, and then integrating that disk prober into our ECS as part of the "scanning" system that creates the device entities in the world.
blkidbindings had already been created before, but it required a number of improvements to support fetching all of the data that needs to be fetched.
libcryptsetupbindings did not exist, but luckily they were easy to create during a fraction of the time in a day's work. Figuring out how to source LVM information was a challenge, however. I learned that the LVM2 project has deprecated access to their C APIs, which will soon no longer exist at all in future packaging. Instead, they recommend using their
lvmdbus1DBus API, which does not have any documentation outside of what you can generate through DBus introspection. Documentation has never been one of Red Hat's strengths.
By the end of the week, the ECS became fully functional as a way to fetch information about devices in the system. Not only is it able to source information about disks and their partitions, but also device maps, loopback devices, logical volumes, physical volumes, and LVM volume groups. An example in the examples directory was created to experiment with the API for fetching data, and as a demonstration for how the API can be interacted with. In the next week additional data will be collected as I experiment further with different component types and association strategies, in addition to experimenting with modifying devices in the world, and APIs to enable this for callers to interact with.
Luckily, a sizeable amount of code was able to be salvaged from the prior ECS experiment, as well as from distinst and its surrounding crates.