b0628fc7b9
This change implements the ability to get and set the WiFi back-end, by leveraging a new script created for that purpose. The idea is to be able to use 'wpa_supplicant' (which is the default back-end in NetworkManager upstream) when 'iwd' (the default in SteamOS) does not work for some reason. This change interacts with another feature of steamos-manager, which is to set debug mode for WiFi. Handling debug mode complicates things substantially because those methods write config for 'iwd' and restart the daemons/systemd units, with many interdependencies. Instead of trying to implement all at once and attempt feature-parity between back-ends on this aspect from the start, as a first step the operations are just declared incompatible. As a result, if WifiDebugMode=on the back-end cannot be changed, and conversely the WifiDebugMode cannot be turned on when the back-end is 'wpa_supplicant'. Co-authored-by: Manuel A. Fernandez Montecelo <mafm@igalia.com> |
||
|---|---|---|
| bin | ||
| data | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| com.steampowered.SteamOSManager1.xml | ||
| HACKING.md | ||
| LICENSE | ||
| README.md | ||
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.