pxcloud/sunshine-sdk
5
0
Fork 0
mirror of https://github.com/thinkonmay/sunshine-sdk.git synced 2025-12-26 14:41:14 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs(guides): add autostart guide (#3287)

Browse Source 
Co-authored-by: ReenigneArcher <42013603+ReenigneArcher@users.noreply.github.com>
This commit is contained in:
A Literal Midwestern Rodent 2024-10-16 15:57:23 -05:00 committed by GitHub
parent f429d34ef5
commit d80fe79f81
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 593 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/app_examples.md
View File

@ -238,6 +238,23 @@ This script is intended as a drop-in replacement with the same syntax. (It can b
| Do | @code{}sh -c "kscreen-doctor output.HDMI-A-1.mode.${SUNSHINE_CLIENT_WIDTH}x${SUNSHINE_CLIENT_HEIGHT}@${SUNSHINE_CLIENT_FPS}"@endcode |
| Undo | @code{}kscreen-doctor output.HDMI-A-1.mode.3840x2160@120@endcode |
@attention{The names of your displays will differ between X11 and Wayland.
Be sure to use the correct name, depending on your session manager.
e.g. On X11, the monitor may be called ``HDMI-A-0``, but on Wayland, it may be called ``HDMI-A-1``.
}
@hint{Replace ``HDMI-A-1`` with the display name of the monitor you would like to use for Moonlight.
You can list the monitors available to you with:
```
kscreen-doctor -o
```
These will also give you the supported display properties for each monitor. You can select them either by
hard-coding their corresponding number (e.g. ``kscreen-doctor output.HDMI-A1.mode.0``) or using the above
``do`` command to fetch the resolution requested by your Moonlight client
(which has a chance of not being supported by your monitor).
}
###### NVIDIA
| Prep Step | Command |

582
docs/guides.md
View File

@ -50,6 +50,10 @@ The virtual display is accelerated by the NVidia GPU using the TwinView configur
I also only tested this on an Artix runit init system on LAN.
I didn't have to do anything special with pulseaudio (pipewire untested).
Pipewire does not seem to work when Sunshine is started over an SSH session.
A workaround to this problem is to kill the Sunshine instance started via SSH, and start a new one
with the permissions of the desktop session. See [Autostart on boot without auto-login](#autostart-on-boot-without-auto-login)
Keep your monitors plugged in until the [Checkpoint](#checkpoint) step.}
@tip{Prior to editing any system configurations, you should make a copy of the original file.
@ -291,13 +295,25 @@ To enable root login over SSH edit your SSHD config, and add `PermitRootLogin ye
sudo cp /etc/sudoers.d/${USER} /etc/sudoers.d/${USER}.backup
```
2. `cd` to the parent dir of the `sunshine-setup.sh` script.
3. Execute the following to update your sudoer config file.
2. `cd` to the parent dir of the `sunshine-setup.sh` script and take note of the full filepath.
3. Execute the following to edit your sudoer config file.
```bash
echo "${USER} ALL=(ALL:ALL) ALL, NOPASSWD: $(pwd)/sunshine-setup.sh" \
| sudo tee /etc/sudoers.d/${USER}
```
@danger{NEVER modify a file in ``sudoers.d`` directly. Always use the ``visudo`` command. This command checks your changes
before saving the file, and if the resulting changes would break sudo on your system, it will prompt you to fix
them. Modifying the file with nano or vim directly does not give you this sanity check and introduces the
possibility of losing sudo access to your machine. Tread carefully, and make a backup.}
```bash
sudo visudo /etc/sudoers.d/${USER}
```
Copy the below configuration into the text editor. Change `${USER}` wherever it occurs to your username
(e.g. if your username is `sunshineisaawesome` you should change `${USER}` to `sunshineisawesome`)
or modify the path if you placed `sunshine-setup.sh` in a different area.
```
${USER} ALL=(ALL:ALL) ALL, NOPASSWD: /home/${USER}/scripts/sunshine-setup.sh
```
These changes allow the script to use sudo without being prompted with a password.
@ -484,6 +500,560 @@ and refresh rate prior to connecting to an app. See
[Changing Resolution and Refresh Rate](md_docs_2app__examples#changing-resolution-and-refresh-rate)
for more information.}
### Autostart on boot without auto-login
| Author | [MidwesternRodent](https://github.com/midwesternrodent) |
| ---------- | ------------------------------------------------------- |
| Difficulty | Intermediate |
After following this guide you will be able to:
1. Turn on the Sunshine host via Moonlight's Wake on LAN (WoL) feature.
2. Have Sunshine initialize to the login screen ready for you to enter your credentials.
3. Login to your desktop session remotely, and have your pipewire audio and Sunshine tray icon work appropriately.
#### Specifications
This guide was created with the following software on the host:
1. OpenSSH server and client (both on the host machine)
2. Sunshine v2024.1003.1754422
3. Debian 12 w/ KDE Plasma, SDDM, Wayland (also tested through xorg), and pipewire for audio.
The host hardware that was used in developing this guide:
1. AMD 7900XTX
2. AMD Ryzen 7 7800X3D
3. 128GB DDR5 RAM
4. 4 displays in total. 2 1080p displays, 1 3440x1440 display, and 1 4k Roku TV which is used as the always-on display
for streaming. (could be subbed with a dummy plug).
If you have used this guide on any alternative hardware or software (including non-debian based distros)
please, feel free to modify this guide and keep it growing!
#### Caveats
1. When you login the machine will close your connection and you will have to reconnect. This is necessary due to an
issue similar to why the [Uinput Permissions Workaround](#uinput-permissions-workaround) is needed since SSH
connections are not treated the same as graphical logins. This causes weirdness like sound not working through
pipewire, and the tray icon for Sunshine not appearing. To get around this, we need to close the SSH initiated Sunshine
service, and start a new Sunshine service with the permissions of the graphical desktop. Unfortunately, this closes the
connection and forces you to reconnect through Moonlight. There is no way around this to the best of my knowledge
without enabling auto-login.
3. This guide does not cover using virtual displays. If you are using Nvidia graphics,
see [Remote SSH Headless Setup](#remote-ssh-headless-setup). If you are using AMD hardware, let me know
if you find something or feel free to add it to this guide.
4. I haven't (yet) found a way to disable sleep on the login screen, so if you wait too long after starting your PC,
the display may go to sleep and Moonlight will have trouble connecting. Shutting down and using WoL works great
though.
@attention{This is definitely safer than enabling auto-login directly, especially for a dual-use PC that is not only
streamed via Moonlight, but is also used as a standard desktop. *However* I do not know the implications of having an
always running SSH client to the localhost on the same machine. It may be possible for someone with significant
knowledge and physical access to the machine to compromise your user account due to this always-running SSH session.
However, that's better than just having the desktop always available, or opening up SSH even just your LAN since this
guide specifically disables non-localhost connections, so I believe this is safer to use than auto-login for general
users. As always, your [threat model](https://en.wikipedia.org/wiki/Threat_model) may vary.}
#### Prerequisites
In [Remote SSH Headless Setup](#remote-ssh-headless-setup) complete the following sections.
1. [Static IP Setup](#static-ip-setup)
2. [SSH Server Setup](#ssh-server-setup)
3. [Virtual Display Setup](#virtual-display-setup)
4. [Uinput Permissions Workaround](#uinput-permissions-workaround)
5. [Stream Launcher Script](#stream-launcher-script)
@note{On a default Debian 12 install using KDE Plasma, you are using the Simple Desktop Display Manager (SDDM).
Even if you are logging in to a Wayland session, SDDM by default starts with an xorg session, so this script
does not need to be modified if you primarily use a Wayland session (the default) when you login.}
#### Instructions
##### Enable Wake on LAN
Wake on LAN (WoL) will allow you to send a magic packet to turn your PC on remotely. This is handled automatically by
Moonlight's "send wake on lan" option in the app but you do need to enable it on your host machine first. The
[instructions on the debian.org](https://wiki.debian.org/WakeOnLan#Enabling_WOL) site are a little hard to parse, so
I've simplified them below.
@note{This may not work on all deb based distributions. If you know of a better way for POP OS, Ubuntu, or another
debian based distro please feel free to edit the guide yourself, or let me know.}
First, find the name of your ethernet interface.
```bash
ip link show
```
When I run this command, these are the results I receive
```
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp117s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
   link/ether 9c:6b:00:59:33:c1 brd ff:ff:ff:ff:ff:ff
```
We can ignore the loopback interface, and I can see my ethernet interface is called `enp117s0`. You might see
wireless interfaces here as well but they can also be ignored.
@note{If your PC is only connected via Wi-Fi, it is still technically possible to get this working, but it is outside
the scope of this guide and requires more networking knowledge and a Wi-Fi chip that supports WoL. If this is your
first foray into linux, I'd recommend just getting a cable.}
Now I can install ethtool and modify my interface to allow Wake on LAN. For your use, replace `enp117s0` with whatever
the name of your ethernet interface is from the command `ip link show`
```bash
sudo apt update
sudo apt install ethtool
sudo ethtool -s enp117s0 wol g
```
##### SSH Client Setup
To start, we need to install an SSH client (which is different from the *server* in [Remote SSH Headless Setup](#remote-ssh-headless-setup))
on our machine if this not already done. Open a terminal and enter the following commands.
```bash
sudo apt update
sudo apt install openssh-client
```
Next we need to generate the keys we will use to connect to our SSH session. This is as simple as running the
following in a terminal:
```bash
ssh-keygen
```
and simply pressing enter through the default options. This will place a file called `id_rsa` and `id_rsa.pub`
in the hidden folder `~/.ssh/`. This is the default key used when this user initiates an SSH session.
Next, we'll copy that public key to the `~/.ssh/authorized_users` file. These are the public keys
allowed to access this machine over SSH, and will allow us to establish an SSH connection with this user
to the SSH server running on the localhost.
```bash
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
```
@tip{If you also want any other machines (e.g. a laptop or Steam Deck) to connect to your machine remotely over ssh,
be sure to generate a pubkey on that machine and append it to the authorized_keys file like we did above.}
###### SSH Server Modifications
We'll want to make a few modification to the SSH server on the Sunshine host, both for convenience and security.
Modify `/etc/ssh/sshd_config` with the following changes:
@tabs{
@tab{nano | ```bash
sudo nano /etc/ssh/sshd_config
```}
@tab{vim | ```bash
sudo vi /etc/ssh/sshd_config
```}
}
Find the line with `PasswordAuthentication` and make sure it is set to `no` (removed the `#` if present.
Then find the line `PubkeyAuthentication` and make sure it is set to `yes` and remove the `#` from the beginning
if present. When you're done you should have these two lines in your config somewhere.
```
PubkeyAuthentication yes
PasswordAuthentication no
```
@tip{Using publickey encryption for SSH connections significantly increases your protection against brute force
attacks, and protects you against a rogue machine pretending to be your SSH server and stealing your password.}
The next step is optional, but if you do not plan on connecting to your computer remotely via ssh and only have
installed SSH for the purposes of using Sunshine, it's a good idea to disable listening for remote SSH connections.
Do this by changing the following lines near the top of your ``sshd_config``:
```
#ListenAddress 0.0.0.0
#ListenAddress ::
```
To the following:
```
ListenAddress 127.0.0.1
ListenAddress ::1
```
This will only allow SSH connections coming from your computer itself.
@tip{on some distributions, the maintainers have added some files in ``/etc/ssh/sshd_config.d/`` which are pulled into
your ``sshd_config``. These modifications can conflict with what we've just done. If you have any files in
``/etc/ssh/sshd_config.d/``, make sure they do not include any of the changes we've just made or you will experience
problems. If they do, you can comment out those lines by placing a ``#`` at their beginning, or delete the files safely
if you don't plan to use SSH for anything other than Sunshine.}
###### Quick Test and Accept Host Authenticity.
Next, let's reboot the machine and try to connect! Accept any warnings about the unidentified host at this time,
you'll never see those appear again unless something changes with your setup.
```bash
ssh $(whoami)@localhost
```
You should see a new login prompt for the machine you're already on, and when you type `exit` you should just see
```bash
logout
Connection to localhost closed.
```
##### Run sunshine-setup on boot over SSH
Thanks to [this comment from Gavin Haynes on Unix Stack exchange](https://unix.stackexchange.com/questions/669389/how-do-i-get-an-ssh-command-to-run-on-boot/669476#669476),
we can establish an SSH connection on boot to run the sunshine-setup script via a systemd service.
###### Disable default Sunshine services
These service files are sometimes overwritten when updating Sunshine with the .deb.
So we'll be making new ones and disabling the included service files for our purposes.
```
sudo sytstemctl disable sunshine
systemctl --user disable sunshine
```
@note{In order to disable the user service, you must be logged in to the graphical desktop environment and run the
command from a GUI terminal. You'll also likely need to approve a polkit request (a graphical popup that asks
for your password). Trying to disable the user service without being signed in to the graphical environment is a
recipe for pain, and is why ``sudo`` is not invoked on the second line in the command above.}
###### Create the autossh-sunshine-start script
@tabs{
@tab{nano | ```bash
sudo nano /usr/local/bin/autossh-sunshine-start
```}
@tab{vim | ```bash
sudo vi /usr/local/bin/autossh-sunshine-start
```}
}
Copy the below script to that location and replace `{USERNAME}` wherever it occurs with the username you created
the SSH public key for in the previous section.
```bash
#!/bin/bash
ssh -i /home/{USERNAME}/.ssh/id_rsa {USERNAME}@localhost
"/home/{USERNAME}/scripts/sunshine.sh"
```
@attention{This script uses the location of the script in [Stream Launcher Script](#stream-launcher-script).
Please complete that section before continuing.}
Once you've created the script, be sure to make it executable by running:
```bash
sudo chmod +x /usr/local/bin/autossh-sunshine-start
```
###### Create the autossh systemd service file
@tabs{
@tab{nano | ```bash
sudo nano /etc/systemd/system/autossh-sunshine.service
```}
@tab{vim | ```bash
sudo vi /etc/systemd/system/autossh-sunshine.service
```}
}
Copy and paste the below systemd file and save it to the location in the commands above.
```
[Unit]
Description=Start sunshine over an localhost SSH connection on boot
Requires=sshd.service
After=sshd.service
[Service]
ExecStartPre=/bin/sleep 5
ExecStart=/usr/local/bin/autossh-sunshine-start
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
```
Make it executable, and enable the service when you're done.
```bash
sudo chmod +x /etc/systemd/system/autossh-sunshine.service
sudo systemctl start autossh-sunshine
sudo systemctl enable autossh-sunshine
```
This point is a good time for a sanity check, so restart your PC and try to sign in to your desktop via Moonlight.
You should be able to access the login screen, enter your credentials, and control the user session. At this point
you'll notice the reason for the next section as your audio will be non-functional and you won't see any tray icon
for Sunshine. If you don't care about audio (and maybe a couple other bugs you might encounter from time to time due
to the permissions difference between an SSH session and the desktop session), you can consider yourself finished at
this point!
@note{You might also notice some issues if you have multiple monitors setup (including the dummy plug), like the mouse
cursor not being on the right screen for you to login. We will address this in the last step of this guide. It requires
messing with some configs for SDDM.}
##### Getting the audio working
To get the audio (and tray icon, etc...) working we will create a systemd user service, that will start on a graphical
login, kill the autossh-sunshine system service, and start Sunshine just like the standard Sunshine service.
This service will also need to call the autossh-sunshine system service before it is stopped as the user service will
be killed when we log out of the graphical session, so we want to make sure we restart that SSH service so we don't
lose the ability to log back in if we need to.
@tabs{
@tab{nano | ```bash
sudo nano /usr/lib/systemd/user/sunshine-after-login.service
```}
@tab{vim | ```bash
sudo vi /usr/lib/systemd/user/sunshine-after-login.service
```}
}
Once again, copy the below service file into your text editor at the location above.
```
[Unit]
Description=Start Sunshine with the permissions of the graphical desktop session
StartLimitIntervalSec=500
StartLimitBurst=5
[Service]
# Avoid starting Sunshine before the desktop is fully initialized.
ExecStartPre=/usr/bin/pkill sunshine
ExecStartPre=/bin/sleep 5
ExecStart=/usr/bin/sunshine
ExecStopPost=/usr/bin/systemctl start autossh-sunshine
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=xdg-desktop-autostart.target
```
Make it executable, and enable it.
```bash
sudo chmod +x /usr/lib/systemd/user/sunshine-after-login.service
systemctl --user enable sunshine-after-login
```
###### Polkit Rules for Sunshine User Service
Since this is being run with the permissions of the graphical session, we need to make a polkit modification to allow
it to call the system service autossh-sunshine when this user service is stopped, without prompting us for a password.
@tabs{
@tab{nano | ```bash
sudo nano /etc/polkit-1/rules.d/sunshine.rules
```}
@tab{vim | ```bash
sudo vi /etc/polkit-1/rules.d/sunshine.rules
```}
}
Once again, copy the below to the .rules file in your text editor.
```js
polkit.addRule(function(action, subject) {
   if (action.id == "org.freedesktop.systemd1.manage-units" &&
       action.lookup("unit") == "autossh-sunshine.service")
   {
       return polkit.Result.YES;
   }
})
```
###### Modifications to sudoers.d files
Lastly, we need to make a few modifications to the sudoers file for our users. Replace {USERNAME} below with your
username. You will be prompted to select either vi or nano for your editor if you've not used this command before,
choose whichever you prefer.
```
sudo visudo /etc/sudoers.d/{USERNAME}
```
@danger{NEVER modify a file in ``sudoers.d`` directly. Always use the ``visudo`` command. This command checks your changes
before saving the file, and if the resulting changes would break sudo on your system, it will prompt you to fix
them. Modifying the file with nano or vim directly does not give you this sanity check and introduces the
possibility of losing sudo access to your machine. Tread carefully, and make a backup.}
As always, copy and paste the below into your user's `sudoers.d` configuration. Replace {USERNAME} with your username,
and {HOSTNAME} with the name of your computer.
```
{USERNAME} {HOSTNAME} = (root) NOPASSWD: /home/{USERNAME}/scripts/sunshine-setup.sh
{USERNAME} {HOSTNAME} = (root) NOPASSWD: /bin/sunshine
{USERNAME} {HOSTNAME} = (root) NOPASSWD: /usr/bin/systemctl start autossh-sunshine
{USERNAME} {HOSTNAME} = (root) NOPASSWD: /usr/bin/systemctl --user start sunshine-after-login
# The below is optional, but will allow us to send trigger a shutdown with a sunshine prep command, if desired.
{USERNAME} {HOSTNAME} = (root) NOPASSWD: /usr/sbin/shutdown
```
Once again, restart your computer and do a quick test. Make sure you can connect to the PC to login and enter your
credentials. You should be booted out of the system, and then can reconnect a few seconds later to the logged-in
desktop session. You should see a tray icon for Sunshine, and the sound should be working (or you may need to manually
select the sunshine-sink at least the first time).
If you don't have multiple monitors, at this point you can consider yourself done!
##### Configuring the login screen layout for multiple monitors
This is not Sunshine specific, but is a frequent problem I had setting up Sunshine and thought it pertinent to add to
the guide. If you are using multiple monitors (even a single monitor with a dummy plug may have this problem) you
might notice the streamed login screen has one or more of the following problems:
1. The text is way too small to see (caused by a too-high resolution)
2. The mouse cursor is off on some other screen (caused by not mirroring the displays)
3. There are multiple login screens overlapping each other (caused by differing resolutions, and trying to mirror
the display).
###### Log in to an X11 Session
This can be fixed, by modifying some scripts called by SDDM on boot. To start though, we need to make sure we're
logged into an x11 session, not Wayland or the terminal. As the Wayland session will give us incorrect information,
and the terminal will give us no information since no graphical environment exists. SDDM initially starts an x11
session to display the login screen so we need to use xorg commands to change the display configuration.
To do this, log out of your desktop session on the Sunshine host, and somewhere on the lower left of your screen
(depending on your SDDM theme) there will be some text that on Debian 12 KDE Plasma defaults to saying
`Session: Plasma (Wayland)`. Select this and choose `Plasma (X11)` from the drop down menu and sign in.
###### Find your monitor identifiers.
Open a terminal and run:
```bash
xrandr | grep -w connected
```
This will require some more sleuthing on your part. Different PC hardware, and different monitors / connectors,
display the names differently. Some start at 0, some start 1. Some spell out "DisplayPort" some, say "DP". You will
need to modify all of the commands from here on out based on the output of the above command. I will use the output I
receive below as the example for the rest of this guide.
```bash
DisplayPort-0 connected (normal left inverted right x axis y axis)
DisplayPort-1 connected (normal left inverted right x axis y axis)
DisplayPort-2 connected (normal left inverted right x axis y axis)
HDMI-A-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 800mm x 450mm
```
@note{If I instead run this command on Wayland, I get the following useless output. Hence the need to sign in to an
x11 session.
```bash
XWAYLAND0 connected 2592x1458+6031+0 (normal left inverted right x axis y axis) 600mm x 340mm
XWAYLAND1 connected 2592x1458+0+0 (normal left inverted right x axis y axis) 480mm x 270mm
XWAYLAND2 connected primary 3440x1440+2592+0 (normal left inverted right x axis y axis) 800mm x 330mm
XWAYLAND3 connected 2592x1458+0+0 (normal left inverted right x axis y axis) 1440mm x 810mm
```
}
From this, you can see that my monitors are named the following under an x11 session.
DisplayPort-0
DisplayPort-1
DisplayPort-2
HDMI-A-0
@tip{If you have a label maker, now would be a good time to unplug some cables, determine where they are on your
system, and label the outputs on your graphics card to ease changing your setup in the future.}
In my setup, after moving some inputs I changed my system so that these cables correspond to the below monitors
| Display Name | Monitor |
| ------------- | --------------------------- |
| DisplayPort-0 | rightmost 1080p display |
| DisplayPort-1 | leftmost 1080p display |
| DisplayPort-2 | middle 3440x1440 display |
| HDMI-A-0 | 4k Roku TV (and dummy plug) |
###### Modify the SDDM startup script
For my purposes, I would prefer to have the Roku TV (which doubles as my always-on dummy plug) to always display a
1080p screen on login (this can be changed automatically after login). And I would like to retain the ability to use
my leftmost monitor to login to my physical desktop, but I'd like to disable my primary and rightmost displays.
To do this, we need to modify the SDDM startup script to shut off DisplayPort-1 and DisplayPort-2, set HDMI-A-0 to
1080p and mirror it with DisplayPort-1.
@tabs{
@tab{nano | ```bash
sudo nano /usr/share/sddm/scripts/Xsetup
```}
@tab{vim | ```bash
sudo vi /usr/share/sddm/scripts/Xsetup
```}
}
Which will open a script that looks like this. We will not be removing these lines.
```bash
#!/bin/sh
# Xsetup - run as root before the login dialog appears
if [ -e /sbin/prime-offload ]; then
   echo running NVIDIA Prime setup /sbin/prime-offload
   /sbin/prime-offload
fi
```
At the bottom of this Xsetup script though, we can add some xrandr commands
To shut a display off, we can use: `xrandr --output {DISPLAYNAME} --off`.
To set a display as the primary and accept
it's automatic (usually the maximum, but not always especially on TVs where the default refresh rate may be lower)
resolution and refresh rate we can use: `xrandr --output {DISPLAYNAME} --auto --primary`.
To set a display to a specific resolution we can use: `xrandr --output {DISPLAYNAME} --mode {PIXELWIDTH}x{PIXELLENGTH}`.
And lastly, to mirror a display we can use: `xrandr --output {DISPLAYNAME} --same-as {ANOTHER-DISPLAY}`
So with my desire to mirror my TV and left displays, my Xsetup script now looks like this:
```bash
#!/bin/sh
# Xsetup - run as root before the login dialog appears
if [ -e /sbin/prime-offload ]; then
   echo running NVIDIA Prime setup /sbin/prime-offload
   /sbin/prime-offload
fi
xrandr --output DisplayPort-0 --off
xrandr --output DisplayPort-2 --off
xrandr --output DisplayPort-1 --auto --primary
xrandr --output HDMI-A-0 --mode 1920x1080
xrandr --output HDMI-A-0 --same-as DisplayPort-1
```
Save this file, reboot, and you should see your login screen now respects these settings. Make sure when you log
back in, you select a Wayland session (if that is your preferred session manager).
#### Next Steps
Congratulations! You now have Sunshine starting on boot, you can login to your session remotely, you get all the
benefits of the graphical session permissions, and you can safely shut down your PC with the confidence you can
turn it back on when needed.
@seealso{As Eric Dong recommended, I'll also send you to automate changing your displays.
You can add multiple commands, to turn off, or configure as many displays as you'd like with the sunshine prep
commands. See [Changing Resolution and Refresh Rate](md_docs_2app__examples#changing-resolution-and-refresh-rate)
for more information and remember that the display names for your prep commands, may be different than what you
found for SDDM.}
## macOS
@todo{It's looking lonely here.}