SteamOS Manager is a system daemon that aims to abstract Steam's interactions with the operating system.
Find a file
Jeremy Whiting aa86fdd810 Add Cargo.lock file since we are building an application.
Usually when building a library we don't ship Cargo.lock, since
binary using our library should control versions. Since we are
an application though, ship Cargo.lock to lock versions of
dependencies.
2023-09-29 13:02:31 -06:00
src Add initial dbus interface xml descripiton. 2023-09-29 13:01:33 -06:00
.gitignore Initial commit. Readme.md and Cargo.toml for now. 2023-08-31 08:08:13 -06:00
Cargo.lock Add Cargo.lock file since we are building an application. 2023-09-29 13:02:31 -06:00
Cargo.toml Add initial dbus interface xml descripiton. 2023-09-29 13:01:33 -06:00
com.steampowered.SteamOSManager1.xml Add initial dbus interface xml descripiton. 2023-09-29 13:01:33 -06:00
Hacking.md Add a basic Hacking.md for getting started, building, running, etc. 2023-09-05 14:16:34 -06:00
Readme.md Initial commit. Readme.md and Cargo.toml for now. 2023-08-31 08:08:13 -06:00

This is the SteamOS Manager.

It is a small daemon that's sole purpose is to give Steam something with a dbus api that runs as root and can do things to the system without having to have hard coded paths and dbus apis in the Steam client itself.

It is a thin wrapper around other scripts and dbus apis that provides feedback for each dbus method it implements.

How it works:

The SteamOS Manager reads various config files (one per thing that it needs to support) that have a DBus method defined in them along with the parameters needed for that method. When it reads each config file it creates a DBus method on it's interface that other applications and processes can call. When each method is called, either the script referred to in the config is called and output and exit codes are given back to the caller, or a dbus method is called from another daemon and the feedback it gets is given back to the caller.

To add a new method:

Add a new config file (more on this later once we flesh out details) with the method name, parameters and what should happen when it is called. For most dbus type methods, the incoming method and parameters will likely closely resemble what we call on another daemon. The purpose of this is to make it flexible for various operating systems to do things their own way. For example on a system that doesn't want to include systemd many systemd type operations could be carried out by scripts instead of calling a systemd dbus api.