Over the past few months, System76 has been developing a simple, easy-to-use tool for updating firmware on Pop!_OS and System76 hardware. Today, we’re excited to announce that you can now check and update firmware through Settings on Pop!_OS, and through the firmware manager GTK application on System76 hardware running other Debian-based distributions.



One of the issues we faced with with firmware management on Linux was the lack of options for graphical frontends to firmware management services like fwupd and system76-firmware . For fwupd , the only solutions available were to distribute either GNOME Software or KDE Discover, which is not viable for Linux distributions which have their own application centers, or frontends to package managers. For system76-firmware , an official GTK application existed, but it only supported updating System76 firmware, when it would be more ideal if it could support updating firmware from both services.

fwupd is a system service which connects to system76-firmware is our own system service which connects to System76 to check for firmware updates for System76 hardware. is a system service which connects to LVFS to check for firmware updates to a wide variety of hardware from multiple vendors.is our own system service which connects to System76 to check for firmware updates for System76 hardware.

Privacy

To increase privacy, we have disabled telemetry reporting in fwupd on Pop!_OS.

To solve this problem, we’ve been working on the Firmware Manager project, which we will be shipping to all Pop!_OS users, and System76 hardware customers on other Debian-based distributions. It supports checking and updating firmware from LVFS and system76-firmware services, is Wayland-compatible, and provides both a GTK application and library.

Wayland disallows applications from being run as root, so applications must either call pkexec to prompt the user for permission to run a background process that is root, or connect to an existing background service provided the needed capabilities.

In Pop!_OS, the firmware manager will be integrated into GNOME Settings in a new Firmware panel under the Devices category with the GTK widget library. Users can simply install the latest updates to use the firmware manager. For other Linux distributions, and for those who do not use GNOME, the GTK application is available to provide the firmware manager widget as a standalone application in its own application window.

Although we’ve created a GTK application and widget library for our use in Pop!_OS, the core framework is toolkit-agnostic, thereby enabling firmware manager frontends to be written in any toolkit. However, it should be noted that since the framework is written in Rust, frontends would need to use Rust in order to interact with it.

GNOME Settings Integration

Pop!_OS will be integrating a patch into GNOME Settings which embeds the GTK widget into a new Firmware panel in the Devices category section.

GTK Application

On System76 hardware running Ubuntu, the firmware manager application will replace System76 Firmware as the source of firmware updates. Other Linux distributions which would prefer to have a standalone desktop application are free to use the included GTK application.

Implementation Details

Like all of our projects today, it is written in Rust, and adheres to current best practices. The project is configured as a workspace, with the core crate providing a generic library for discovering and managing firmware from multiple firmware services. Both fwupd and system76-firmware are supported.

The core is used as the foundation for the two members of this workspace: a notification binary to provide desktop notifications about firmware updates; and a GTK project which serves as both a widget library and desktop application.

Visualization of project structure

* firmware-manager * firmware-manager-notify * firmware-manager-gtk * firmware-manager-gtk-ffi

Core Library

The firmware-manager library provides functions for scanning firmware, as well as an event loop which receives and sends event signals through channels. One channel receives messages from the frontend, whereas the other sends messages to the frontend. This is designed to be run in a background thread in order to prevent a UI that uses the firmware manager from blocking as requests are being processed.

Additionally, the event API is expected to be used with the provided slotmap -based entity-component architecture. This allows a frontend to assign entity IDs to their requests, and receive those entity IDs back in responses. In doing so, frontends can avoid the need for complex runtime reference-counting, or creating reference cycles. The frontend has exclusive ownership of the data that an entity ID refers to.

GTK Application / Library

The firmware-manager-gtk member of the project provides the firmware widget as a library, and an application which places that widget into a window. This member contains a C FFI sub-member, which builds a dynamic library with a C API and header, and can be used to integrate the widget into any GTK application written in C.

This implementation takes full advantage of the slotmap EC, assigning its own component storages to keep track of state relative to a device entity, such as the widgets assigned to an entity, and information about their firmware.

The included GTK application statically-links the Rust widget library into the binary.

Notification Binary

The firmware-manager-notify member comes with a systemd user timer so that it is executed at login, and then periodically run again at set intervals to check for updates again. When updates are found, a clickable notification will be displayed, which will either open the Firmware panel in GNOME Settings, or the standalone desktop application, depending on which is available on the system.

Supporting Other Frontends

Although the project will release with only a GTK frontend, it is possible for anyone to use it as the foundations for developing a frontend written in any other graphical toolkit. All functionality in the core library is GUI-agnostic, and the entity-component architecture can be extended to their specialized needs. If you write a frontend for another toolkit and want it included in the project, feel free to submit a pull request!

For more details on the new firmware manager, check out Michael Aaron Murphy’s article on GitHub.

