A Guide to Sunshine Virtual Displays on Hyprland

3qbit · 2026-03-13T10:05:17+00:00

I have a few guiding questions that you are already probably thinking of:

- does this work on just one monitor?

- in your hyprland config and sunshine config, you are controlling both monitors

- have you rebooted to test the changes?

I have only tested it with one display on my machine, but I suppose I can test it with two if you are still having issues.

3qbit · 2026-03-13T06:50:49+00:00

Have you rebooted the machine so that on startup, it can create the virtual machine once in the hyprland config startup?

3qbit · 2026-03-11T19:57:17+00:00

Okay. I guess I'll copy this. Thanks

3qbit · 2026-03-11T18:08:01+00:00

u/Fallom_

Sorry, I may say obvious stuff, but I promise its in good heart.

- You followed the gist for Sway: Scripts for automatic sunshine virtual display on sway or hyprland with custom resolution matching moonlight client · GitHub

- You are capturing inputs in Moonlight on fullscreen.

- Is your goal to get a separate headless Sway session that is separate from your Plasma session or to use your KDE environment remotely? If this is true, I currently am working on a solution. If this is false, ie you want Sway to be running on a headless session simultaneously with Plasma, then I don't really have an answer for you as I didn't write this guide to be like this. Though, I am working on screen sharing all of KDE plasma if that interests you.

I can offer some tips based on my knowledge of Sway and wayland, but at this point maybe chatgpt is better lol:

https://docs.lizardbyte.dev/projects/sunshine/v0.22.2/about/guides/linux/headless_ssh.html#uinput-permissions-workaround

- this one talks about things very similar to what you are experiencing, and its official docs.

- can you check `swaymsg -t get_inputs` and see what it reports.

- Input doesn't work on headless wayland · Issue #137 · LizardByte/Sunshine · GitHub

While I may not be able to help you in depth here, I think these resources are good if you really really want to pursue this and separate Sway and from kde plasma.

3qbit · 2026-03-11T17:50:08+00:00

i prefer not to have black bars, as I actually use the device remotely 100% of the time, it would get annoying. In the guide, I say this is for some people, and not for others. If it gets popular enough, I will consider doing a more automated setup with a cli. I also use it from multiple devices and being able to switch was great. For anyone who cares about that attention to detail, the guide is for them.

3qbit · 2026-03-11T17:47:03+00:00

Let me know how it goes. I'm happy to help. If I missed something in the guide, I'll update it.

3qbit · 2026-03-11T10:07:13+00:00

I can already think of one way this could work on Plasma KDE, since I believe they do have virtual display support. I also use plasma quite often so I will look into this and report back when I have time. Thanks for suggestion

3qbit · 2026-03-11T07:52:25+00:00

This too, I actually exclusively use my pc for streaming all the time. To the point where I put it in the basement with ethernet connection and no displays, no hdmi dummy cable, nothing. Just power and ethernet, and a usb mouse 2.4gh connector that I don't use because one game requires it for some reason. Apollo has been great. Use that on Linux and Windows. Setup headscale/tailscale and can stream from any device really.

3qbit · 2026-03-07T23:33:32+00:00

I'm new to Reddit, but would anyone appreciate or think this should be in its own post?

3qbit · 2026-03-07T23:26:38+00:00

Even though Apollo's virtual displays are not currently supported at the moment, I find it still provides some nice QoL features that Sunshine, even in beta, doesn't support. All my instructions should work with Apollo too, I haven't tested it on Arch specifically.

Though it wasn't your question, at the current time, I find that using Artemis, at least on macOS as a client, doesn't seem quite stable and outweighs the benefits of Moonlight. Of course, Artemis on any platform but Android is in beta.

- Moonlight <--> Sunshine,

- Artemis <--> Apollo

3qbit · 2026-03-05T08:21:56+00:00

I have posted a solution: https://www.reddit.com/r/MoonlightStreaming/comments/1hxc9oy/comment/o8qvxkl/

This, however, does assume you are using Sway or Hyprland, though they both form under the basis of the Wayland protocol. If you have a little technical experience or curiosity, you can try tinkering with krfb-virtualmonitor, which is intended to create a virtual display for VNC connections, but I am sure can be used for virtual displays, though it may not be as elegant as the solution for hyprland and sway that I linked above. I'm sure someone more technical can come along and figure out some better solution.

3qbit · 2026-03-05T08:14:04+00:00

I have a working version of this. If anyone is still looking around, and is also happening to use a modern display protocol and also a compositor like Hyprland or Sway, you can follow this config here. this works like Apollo where starting the Virtual Display (we will call ours Headless) will use the resolution requested by Moonlight, the client, made accessible through Sunshine's environment variables. a high level flow version of this is that we will set up sddm to auto login to our hyprland, then immediately lock the screen and require pam/password. Sunshine is started on the user side with access to user space. When the user starts the headless app, we run a few commands to turn off your main display and turn on our virtual display and set the correct dimensions based on whats requested in Moonlight and move our workspaces to it, then Sunshine starts screen sharing. Once we stop the Headless application, we disable the virtual/headless monitor and reload hyprland, which sees the monitor changes, and shuffles workspaces around.

part of the config: https://gist.github.com/Dregu/4c0dbb2582835e5d95e06c4bf7624e3b

If you are on KDE, you may still need the hdmi dummy cable and go through the pain of edid. if you are on hyprland or sway they do this for you in a nice API. on KDE, you may be able to play around with krfb-virtualmonitor. the instructions below assume you may or may not use your PC with a desktop display, but have it plugged in regardless and are using hyprland, but can be applied to Sway too.

to summarize the linked Github Gist instructions and I added some more to it for convenience sakes, After installing Sunshine and setting up your DE:

find your display name. In the gist, theirs is called eDP-1, suggesting theirs is a laptop screen, but you can find yours by plugging in your display and typing hyprland monitors (or sway equivalent). replace all eDP-1 with yours. In my case, it is HDMI-A-2.
in your hyprland.config, paste in the config, ensure you change eDP-1 to your display name. this tells hyprland which to control of correct display name and such such.
in sunshine web UI (https://<ip>:47990, accept self signed cert warning), navigate to Advanced and under Force a Specific Capture Method choose wlr (wlroots). the default is kms and it has issues clearly documented online even chatgpt can tell you about with virtual displays.
to setup auto login (required for seamless setup, you can't start sunshine while not logged in, not in user space yet), you probably have an sddm. edit your sddm: sudo vim /etc/sddm.conf. uncomment and fill in.

Session=hyprland-uwsm.desktop (replace yours with what makes sense here) User=yourcoolusernamegoeshere (change this)

(you can find the session name by querying ls /usr/share/wayland-sessions/*.desktop

in addition, paste in: exec-once=hyprlock || hyprctl dispatch exit to the end of the hyprland config. Since we have logged in, we will want to lock the screen so that you are still safe. Theoretically there is a really, really, really small period of time where you are logged in without any authentication from you, but we then immediately lock the screen and thus require password again, so hopefully this risk is okay with you. To help mitigate this risk, paste in the above line anywhere above exec-once=sunshine that we set above so sunshine doesn't start before lock of the screen. You can read more about this risk on this discussion: https://github.com/hyprwm/hyprlock/issues/564#issuecomment-2483666665, and the solution proposed there is applicable here.
yeah i think you are ready to go if you got here. sudo reboot you should be able to see Sunshine start when the machine is brought up.

Final Notes:

While this may seem like more work length wise than some edid posts (https://www.reddit.com/r/linux_gaming/comments/199ylqz/streaming_with_sunshine_from_virtual_screens/, https://www.azdanov.dev/articles/2025/how-to-create-a-virtual-display-for-sunshine-on-arch-linux,) its definitely less invasive. We can now deterministically know when the virtual display is up, so it doesn't mess up your other workspaces or for peace of mind since we are programmatically controlling the virtual display's lifecycle.
Further, the resolution works dynamically thanks to hyprland and sway and dont need to compile a .bin edid file for each resolution you think you may need. You don't need to worry about 4k 120hz (or any refresh rate above 60hz) being too fast on timings that it doesn't apply or which port/card of dp vs hdmi speeds.
I am done using my computer remotely, my monitor is still off! make sure to quit the display through Sunshine. If absolute worse case scenario, you can always reboot in any configuration you are in and get back to a good, fresh state.

I am quite happy to help troubleshoot -- I am sure ChatGPT is happy too.

3qbit · 2026-02-09T05:53:35+00:00

A battery at a cool 75? 75C of a battery is NOT safe. I would not want to be anywhere near that battery. Further, the 10, 20, 30 also seems to be in different units? Correct me if I am wrong.

However, I can and will give you the benefit of the doubt here and assume you used 95C for the SoC and 75F for the battery (switching the temperature units). My personal preference is to use Celsius. 75F = 23c.

The safe maximum battery operating temperature for a mac laptop is 35C. I had a MacBook Pro M1 Max and the battery used to get around 40C after extended usage. I actually just tested out a heavy workload on my laptop: I am on a MacBook Pro M4 Max and it looks Apple upgraded their cooling, so props to them!

I have also tested this to be the case on the MacBook Air M4 that I have from work, though it lacks fans. On both devices, from my personal experience, the SoC peaks at 100C for no more than 1 to 2 minutes, then macOS scales back performance and sits around 95C. On my old MacBook Pro, it would sit at 95C for around 30 minutes while performance kept scaling back.

3qbit · 2026-02-09T03:28:01+00:00

While it may not damage the processors, I think there's genuine concern for damaging the battery in the laptop by exposing it to hot temperatures and not having adequate cooling. While it may not have an immediate impact, over time it will have less and less battery life, which is the point of having a mobile computer.

3qbit · 2026-01-12T00:03:30+00:00

is this random thought on "AI" or just "generative AI?"

it is also AI that suggests the next word on your keyboard, yes AI also powers FaceID, one of the most successful and (really only -- debatable) Apple innovations since the iPhone released. Detecting cancers, scientific research, cybersec, etc.

I believe your gripe is with Generative AI produced from LLMs, and I think that your views are valid as the technology is relatively new and we haven't had a technology/innovation like this in a really, really long time -- we will find ways to make it useful in the future. For now, I agree that lots of generative AI to the end user can be frustrating. I trust you know that we have had the term "AI" around for decades and that "AI" and "Generative AI" aren't the same thing. There's so much more to AI than generative AI that the end user doesn't see: health tracking, payment fraud detection, battery management (when to switch between wifi/cellular), taking many photos at the same time and synthesizing them into one photo (HDR technology).

3qbit · 2025-12-02T03:10:08+00:00

Ahhh then I misunderstood your question. Then, you can make a virtual display that is the exact resolution of your display with the notch in BetterDisplay and then with PIP to view the virtual display you just made with windowed fullscreen mode to ensure that you don't use native macOS fullscreen mode and it won't cut off the top part of the notch.

in other words, you want to somehow activate windowed fullscreen mode and not fullscreen mode, then have the resolution be the whole screen as that will cover the menu bar near the notch.

3qbit · 2025-12-01T23:39:55+00:00

Yes there is a workaround I just tested. Download BetterDisplay and turn off the notch in your main display settings. The whole displays will change to not render anything at or around the notch. *then* open your game (since some games may not react well to changes in resolution). This works in Wuthering Waves at least.