SteamOS Manager is a system daemon that aims to abstract Steam's interactions with the operating system.
Find a file
2024-05-17 19:32:27 +00:00
data data: Split user and system data files into respective directories, add user D-Bus unit 2024-05-06 13:26:40 -07:00
src Fix clippy warnings about not needing .to_string() anymore. 2024-05-17 09:40:22 -06:00
.gitignore Merge steamos-workerd in 2024-03-22 19:31:38 -07:00
.gitlab-ci.yml Move CI to isolated runner(s) 2024-05-07 13:42:15 +01:00
Cargo.lock Cargo.toml: zbus 4.2.1 is out, fixes needed issue 2024-05-14 18:09:54 -07:00
Cargo.toml Cargo.toml: Tag 24.5.1 2024-05-14 18:10:17 -07:00
com.steampowered.SteamOSManager1.xml process: Improve signal handling, don't wait for process in exit_code 2024-05-08 16:39:14 -07:00
HACKING.md Revamp README and HACKING to be more fleshed out and up-to-date 2024-05-15 16:49:30 -07:00
LICENSE Add support to get/set WiFi back-end 2024-04-04 18:08:21 -07:00
README.md Update README.md 2024-05-17 19:32:27 +00:00

SteamOS Manager

SteamOS Manager is a system daemon that aims to abstract steam's interactions with the operating system. The goal is to have a standardized interface so that SteamOS specific features in the Steam client, e.g. TDP management, can be exposed in any linux distro that provides an implementation of this DBus API.

The interface may be fully or partially implemented. The Steam client will check which which features are available at startup and restrict the settings it presents to the user based on feature availability.

Some of the features that SteamOS Manager enables include:

  • GPU clock management
  • TDP management
  • BIOS/Dock updates
  • Storage device maintenance tasks
  • External storage device formatting
    • Steam geneally performs device enumeration via UDisks2, but formatting happens via SteamOSManager

For a full list of features please refer to the interface specification.

Other notable dbus interfaces used by the Steam Client include:

  • org.freedesktop.UDisks2
  • org.freedesktop.portal.desktop
  • org.freedesktop.login1
  • org.bluez

Interface compatibility notes

SteamOS Manager and the Steam client are normally updated independently of each other. So the interface must remain binary compatible across releases.

In general, when making changes to the interface please consider the following:

  • Method signatures must not be altered
    • Instead, prefer exposing a new symbol and add a compatibility adapter to the previous interface
  • Changes in behaviour should be avoided
    • Consider how a change would affect the beta and stable release of the Steam client
  • Features must have a mechanism to discover if they are available or not
    • E.g. for a feature exposed as a property if the property is not present on the bus it means the feature is unsupported.

Note that while SteamOS Manager must never break binary compatibility of the interface, the Steam client makes no guarantees that older versions of an interface will be used if available. As a rule of thumb, the client will always provide full support for the SteamOS Manager interface version available in the Stable release of SteamOS.

Implementation details

SteamOS Manager is compromised of two daemons, one runs as the logged in user and exposes a public DBus API on the session bus. And the second daemon runs as the root user and exposes a limited DBus API on the system bus for tasks that require elevated permissions to execute.

The DBus API exposed on the system bus is considered a private implementation detail of SteamOS Manager and it may be changed at any moment and without warning. For this reason, we don't provide an XML schema for the system daemon's interface.

Extending the API

To extend the API with a new method or property first update the XML schema. Then extend the user daemon's DBus API which is implemented in src/manager/usr.rs.

If the new functionality requires elevated privileges, then extend the system daemon's DBus API in src/manager/root.rs with the necessary helpers to complete the task. Please consider keeping as much logic as possible in the user context.

Building

TODO: pretty much a rust standard Building

Running tests

TODO