I’m currently using tailscale vpn and moonlight to play games outside my home.

45m ethernet cable, 1 gigabit ethernet adapter for client and setting virtual display at 4k on vibepollo. Feels like the tv is connected via HDMI to my PC.

I have just one question, the virtual display properties show extremely high refresh rate (400hz or something). What could be the reason behind it?

Moonlight XR is a streaming client for Sunshine/Apollo that allows you to stream any content from your PC to your Quest, Pico (and other) headsets and turn those streams into 3D in real-time. (3D as in 3D movies, not VR).

## Moonlight XR v0.3

This is the biggest update yet, bringing a lot of new features and bug fixes! Hope you all enjoy.

First things first **You will need to uninstall the v0.1 or v0.2 and pair to your pc again** (Should never need to do this again!) The app's package name changed (part of preparing for Google's developer verification), so v0.3 installs

alongside old versions instead of upgrading. Install v0.3, pair with your

host once, then uninstall the old copy. Your host-side settings are untouched.

Everything below was verified on both a Quest 3 and a Pico 4 Ultra. Other headsets have issues? Please send me the logs, you'll find them in the Downloads folder of your headset.

### In-headset settings panel

Allows you to change various settings in real-time, including more granular control of the screen. Any controls not in here can be found in the menu of Moonlight XR's launcher (before immersive mode), some settings such as resolution can only be changed before the stream starts.

### Virtual keyboard

Virtual keyboard for input to host PC.

### Environments: New 3D rooms

Added a "minimal room" and a "PSX Cinema". These are not just 360 images but actual 3D spaces with lighting from the screen impacting them. I will be adding more, much higher quality, over time but for now these were to test that I could do it without a game engine and get a workable result.

The PSX cinema is credit to ["VR Cinema Environment"](https://skfb.ly/6VuIX) by

fangzhangmnm (CC BY 4.0).

### Ambilight

A glow behind the screen, sampled from the picture's edges, Philips style.

On by default as the performance hit is essentially zero and adds a nice effect. It can be toggled off in the realtime settings, and the intensity can also be changed.

### Exit button

Let's you exit without needing to depend on your headset's built in home button. Truly revolutionary stuff!

### Environment Resolution Picker

A new setting for how sharply the 3D rooms render, in the 2D settings menu:

Low (used automatically on Quest 2 era headsets), Standard (the default),

High, and an experimental Ultra that ignores what the headset asks for and

may hitch or stutter. If a room looks aliased to you, try High.

### Settings menu cleanup

Everything you can change live in the headset now lives only there. The 2D settings menu keeps only what has

to be set before a session starts. VR mode also drops its "experimental"

label.

### Sharpening

Compositor sharpening on the screen layers, on runtimes that offer it. It

runs inside the compositor's own sampling pass, so it is free. Defaults to quality, I find everything looks better with it on but it's up to you!

### Bug fixes

- Double-clicking works now.

- Resizing by a corner keeps the screen centred where you put it instead

of walking it toward the dragged corner.

- The corner resize brackets no longer can get stuck within the boundaries of the screen

- The pairing PIN no longer vanishes after a few seconds when you look away

or take the headset off to type it into the host.

- Starting a session with passthrough enabled no longer sometimes comes up

in a black room on Pico.

- Opening a panel with the glow on no longer blanks the display for a

moment on headsets with a low compositor layer limit.

### Smaller things

- The controller laser is filtered with a One Euro filter: steadier on small

buttons, no added lag on fast moves.

- With passthrough off and no environment picked, you now get black rather

than a surprise panorama.

- Picking an environment no longer also clicks whatever was on the host

screen behind the grid.

- A plain text log (Download/MoonlightXR/moonlight.log on the headset) that

you can send with bug reports. Grab it over USB, or simply send it from within your headset.

### Older headsets

On XR2 Gen 1 devices (Quest 2 / Pico 4/Neo 3 Link era) the app now applies a more

conservative first-run profile: 1440p, 72 fps, and a lower depth inference

rate, with realtime 3D kept on. I haven't actually confirmed these are good settings as I don't have any of those headsets right now. If it runs badly (or well!) on yours then please let me know (and send the log file!).

### Known issues

- Occasional audio pops and brief stutters during streams. Under

investigation; current evidence points at the stream path rather than the

renderer. Often settles after the first couple of minutes.

- The disocclusion stretch at object edges in realtime 3D remains; a mono

source cannot supply those pixels, and anything better is future work.

- Keyboard: no pipe/tilde/backtick, no key repeat yet.

Hey everyone,

I’ve been using a TP-Link Deco Wi-Fi 7 mesh system for home networking, with my host gaming rig on the floor above our living room. It worked fine when my client was an Apple TV at 1440p 60 Hz, but once I built a dedicated living room HTPC to push 4K 120 Hz/HDR streams via Vibeshine & Moonlight, wireless packet pacing was rearing its head and leading to micro stutters and frame pacing problems.

We had 3 phone jacks with cat 5e cable but in totally inconvenient locations so I quickly abandoned them, and I did not want to fish new wire because it would be difficult with our home. The house had 7 coax wall ports spread across three floors and the basement. I had avoided MoCA for a while because I didn't know how the builder had routed the lines back in 2006, but I finally decided to unscrew every single wall plate and trace the runs.

I found out that every floor had at least one legacy daisy-chained splitter inside the wall cavity capped at 1000 MHz, which severely attenuates MoCA 2.5. I also found out that these daisy chained lines on each floor all connected to one line that ran outside to two legacy splitters cascaded together on the side of the house.

What I Did

Outdoor Hub: Ripped out the two cascaded exterior splitters and replaced them with a single balanced 4-way MoCA 2.5 Splitter inside a weatherproof capsule. Because we don’t use cable internet, I capped the splitter's ⁠IN⁠ port with a terminator to prevent internal RF reflections, and capped the old cable input line. All ports sealed with dielectric grease, and I cleaned the pins of the connectors with 90% isopropyl alcohol beforehand to get rid of any oxidation that built up over 20 years.

Unused coax ports bypass: For rooms where I didn't need active coax jacks, I removed the old splitters entirely and joined the in-wall cables using 3 GHz female-to-female barrel couplers. Then I switched the coaxial port plate to a plate to one with a blank face. This eliminated unnecessary signal loss and turned that floor run into an unattenuated direct line. If we do need to use that line in the future it just needs to have a splitter installed and the coaxial face plate replaced.

Coax ports in use: Swapped the old in-wall splitters for 2-Way MoCA 2.5 splitters to keep these jacks live.

Cellular Internet: Kept our 5G gateway at its optimal window location for peak cellular metrics, ran a 30 ft flat white Cat 6 cable cleanly along the baseboard, and injected our main mesh router directly into the coax plant via a MoCA 2.5 adapter.

Wired Backhaul: Connected the remaining MoCA adapters directly to my mesh satellite units. These units are also wired to my client HTPC, host rig and Jellyfin server.

I spent about $300 and 2.5 hours of my time. In return I got true 2.5 Gbps across all three floors.
Moonlight runs at 4K 120 fps HDR at 200 Mbps with ~ 5-6ms network transit delay and zero frame drops. All mesh Wi-Fi nodes now run on dedicated wired backhaul as well, freeing up the wireless bands and giving the Steam Deck a rock-solid connection anywhere in the house as well for moonlight streaming. If you have pre-existing coax sitting dead in your walls, opening up the plates and mapping your splitters is an easy and high ROI project. Do it!

I have had streaming working pretty well for a while. But recently the virtual display functionality doesn't seem to work/start via Apollo. Whenever I connect a session via moonlight (SteamOS and xbox) I get my main monitor 1 desktop running at 1440p instead of the virtual 4k one.

• I have always create virtual display checked for both clients.
• I have a 4k Display mode override set.
• I have tried checking the headless option.
• I see a third monitor (either steam machine or legacy moonli for xbox) in the windows display settings. But it "isn't active" even when connected via moonlight.
• I have cleared my monitor cache by deleting the registry as per this link

I can't say I remember changing anything before it stopped working and was wondering if anyone had ideas to fix the virtual display function.

Hi, I’d like to know if anyone has encountered issues similar to mine and could help me get a playable experience. I’m trying to stream from my PC to my living room TV, but I’m running into a few problems.

If I use Moonlight as the client, the stream runs smoothly (stable 60 fps), but my TV freezes and crash if I try to adjust the volume or exit the app, wich makes unplayable. There are forks of Artemis that fix this, but I can't get the stream to run as smoothly on Artemis as it does on Moonlight. On Artemis, it feels like I'm playing at 30 fps, regardless of the settings I choose. I’ve already tested other Artemis forks, like Artemide, but the framerate issue still persists.

It is also worth mentioning that I have tested with several different hosts: Sunshine, Apollo, Vibepollo, and Vibeshine. The problem remains the same: smooth streaming, but TV crashing in Moonlight and low FPS in Artemis.

I’m loosing my mind out trying to find a solution—if anyone can help, I’d appreciate it.

Dynamic Virtual Monitor for Sunshine/Moonlight on KDE Wayland — KRFB + Any Resolution + Dynamic Refresh Rate

I originally made a guide for using a KDE KRFB virtual monitor with Sunshine/Moonlight at 1920×1080 @ 120 Hz.

Since then, I changed the setup significantly.

The new version is fully dynamic:

• No dummy HDMI/DisplayPort plug
• Physical monitor can remain enabled
• No hard-coded resolution
• Resolution comes from the Sunshine/Moonlight client request
• Automatically creates the requested virtual monitor resolution
• Automatically creates missing refresh-rate modes
• Supports 60/90/120/240 Hz
• Works with resolutions such as 1280×800, 1920×1080, 1920×1200, 2560×1440 and 3840×2160
• Automatically positions the virtual monitor beside the physical displays
• No need to manually fix the display position in KDE Display Settings every time

The important part is that KRFB creates the virtual display and KScreen controls its resolution, refresh rate and position.

What the setup does

The basic flow is:

Moonlight
    │
    ▼
Sunshine
    │
    │ client requests resolution/FPS
    ▼
sunshine-vm-dynamic.sh
    │
    ├── creates KRFB virtual monitor
    │
    ├── detects the virtual KScreen output
    │
    ├── positions it automatically
    │
    ├── checks for requested refresh rate
    │
    ├── creates custom mode if necessary
    │
    └── activates requested mode
    │
    ▼
Virtual-sunshine-vm
    │
    ▼
Sunshine
    │
    ▼
Moonlight

The physical monitor does not need to be disabled.

Requirements

This guide is intended for:

• KDE Plasma
• Wayland
• KRFB
• KScreen / kscreen-doctor
• Sunshine
• Moonlight

On Arch/Arch-based systems, install KRFB:

sudo pacman -S krfb

Check that the virtual-monitor executable exists:

krfb-virtualmonitor --help

Also check:

kscreen-doctor --help

You should see the addCustomMode functionality.

STEP 1 — Create the script directory

mkdir -p ~/.local/bin

STEP 2 — Create the dynamic virtual-monitor script

Create:

nano ~/.local/bin/sunshine-vm-dynamic.sh

Paste the following:

#!/bin/bash

set -u

WIDTH="${1:-${SUNSHINE_CLIENT_WIDTH:-1920}}"
HEIGHT="${2:-${SUNSHINE_CLIENT_HEIGHT:-1080}}"
FPS="${3:-${SUNSHINE_CLIENT_FPS:-60}}"

OUTPUT="Virtual-sunshine-vm"
NAME="sunshine-vm"
PASSWORD="CHANGE_THIS_PASSWORD"
PORT="5905"

echo "Dynamic Desktop: ${WIDTH}x${HEIGHT}@${FPS}"

KSCREEN="/usr/bin/kscreen-doctor"

kscreen_output() {
    "$KSCREEN" -o 2>/dev/null |
        sed $'s/\033\\[[0-9;]*m//g'
}

# ------------------------------------------------------------
# Detect Wayland
# ------------------------------------------------------------

export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}"

if [ -z "${WAYLAND_DISPLAY:-}" ]; then
    for socket in "$XDG_RUNTIME_DIR"/wayland-*; do
        [ -S "$socket" ] || continue
        WAYLAND_DISPLAY="$(basename "$socket")"
        export WAYLAND_DISPLAY
        break
    done
fi

if [ -z "${WAYLAND_DISPLAY:-}" ]; then
    echo "ERROR: Could not find a Wayland display."
    exit 1
fi

# ------------------------------------------------------------
# Remove any previous virtual monitor.
# ------------------------------------------------------------

pkill -f '/usr/bin/krfb-virtualmonitor' 2>/dev/null || true
sleep 2

# ------------------------------------------------------------
# Create the virtual monitor at the requested resolution.
# ------------------------------------------------------------

/usr/bin/krfb-virtualmonitor \
    --resolution "${WIDTH}x${HEIGHT}" \
    --name "$NAME" \
    --password "$PASSWORD" \
    --desktopfile org.kde.krfb.virtualmonitor \
    --scale 1 \
    --port "$PORT" &

# ------------------------------------------------------------
# Wait for KScreen to register the virtual monitor.
# ------------------------------------------------------------

FOUND=0

for i in $(seq 1 30); do
    if kscreen_output | grep -q "$OUTPUT"; then
        FOUND=1
        break
    fi

    sleep 0.5
done

if [ "$FOUND" -ne 1 ]; then
    echo "ERROR: Virtual monitor was not detected."
    exit 1
fi

# ------------------------------------------------------------
# Get the KScreen output number.
# ------------------------------------------------------------

OUTPUT_ID=$(
    kscreen_output |
    awk -v name="$OUTPUT" '
        $0 ~ name {
            print $2
            exit
        }
    '
)

if [ -z "$OUTPUT_ID" ]; then
    echo "ERROR: Could not determine output ID."
    exit 1
fi

echo "Virtual monitor output ID: ${OUTPUT_ID}"

# ------------------------------------------------------------
# Automatically position the virtual monitor.
#
# Find the rightmost physical display and place the virtual
# monitor immediately to its right.
#
# No physical resolution is hard-coded.
# ------------------------------------------------------------

PHYSICAL_RIGHT=0
PHYSICAL_Y=0

while read -r ID NAME; do

    if [ "$ID" = "$OUTPUT_ID" ]; then
        continue
    fi

    GEOMETRY=$(
        kscreen_output |
        awk -v id="$ID" '
            $0 ~ "^Output: " id " " {
                inside=1
                next
            }

            inside && /^Output:/ {
                exit
            }

            inside && /Geometry:/ {
                print $2, $3
                exit
            }
        '
    )

    if [ -z "$GEOMETRY" ]; then
        continue
    fi

    POSITION=${GEOMETRY%% *}
    SIZE=${GEOMETRY#* }

    X=${POSITION%,*}
    Y=${POSITION#*,}

    DISPLAY_WIDTH=${SIZE%x*}

    RIGHT=$((X + DISPLAY_WIDTH))

    if [ "$RIGHT" -gt "$PHYSICAL_RIGHT" ]; then
        PHYSICAL_RIGHT="$RIGHT"
        PHYSICAL_Y="$Y"
    fi

done < <(
    kscreen_output |
    awk '/^Output:/ {print $2, $3}'
)

echo "Positioning virtual monitor at ${PHYSICAL_RIGHT},${PHYSICAL_Y}"

if ! "$KSCREEN" \
    "output.${OUTPUT_ID}.position.${PHYSICAL_RIGHT},${PHYSICAL_Y}"; then

    echo "WARNING: Could not automatically position virtual monitor."
else
    echo "Virtual monitor positioned automatically."
fi

# ------------------------------------------------------------
# Find or create the requested refresh rate.
#
# KScreen/KRFB may report 120 Hz as something like 119.xx Hz.
# Therefore a small tolerance is used.
# ------------------------------------------------------------

MODE_ID=""

echo "Checking for ${WIDTH}x${HEIGHT}@${FPS} Hz..."

MODE_ID=$(
    kscreen_output |
    awk \
        -v name="$OUTPUT" \
        -v res="${WIDTH}x${HEIGHT}" \
        -v target="$FPS" '
        $0 ~ name {
            inside=1
            next
        }

        inside && /^Output:/ {
            exit
        }

        inside && /Modes:/ {
            best_id=""
            best_diff=999999

            for (i=1; i<=NF; i++) {

                token=$i

                if (token ~ /^[0-9]+:/ && token ~ res "@") {

                    id=token
                    sub(/:.*/, "", id)

                    mode=token
                    sub(/^[0-9]+:/, "", mode)

                    split(mode, p, "@")
                    rate=p[2] + 0

                    diff=rate-target

                    if (diff < 0)
                        diff=-diff

                    if (diff <= 2 && diff < best_diff) {
                        best_diff=diff
                        best_id=id
                    }
                }
            }

            if (best_id != "") {
                print best_id
                exit
            }
        }
    '
)

# ------------------------------------------------------------
# Requested mode does not exist.
# Create it as a custom mode.
# ------------------------------------------------------------

if [ -z "$MODE_ID" ]; then

    echo "No ${WIDTH}x${HEIGHT}@${FPS} mode found."
    echo "Adding custom ${WIDTH}x${HEIGHT}@${FPS} Hz mode..."

    if ! "$KSCREEN" \
        "output.${OUTPUT_ID}.addCustomMode.${WIDTH}.${HEIGHT}.${FPS}000.full"; then

        echo "ERROR: Failed to add ${WIDTH}x${HEIGHT}@${FPS} custom mode."
        exit 1
    fi

    sleep 1

    # Find the newly-created mode.
    MODE_ID=$(
        kscreen_output |
        awk \
            -v name="$OUTPUT" \
            -v res="${WIDTH}x${HEIGHT}" \
            -v target="$FPS" '
            $0 ~ name {
                inside=1
                next
            }

            inside && /^Output:/ {
                exit
            }

            inside && /Modes:/ {

                best_id=""
                best_diff=999999

                for (i=1; i<=NF; i++) {

                    token=$i

                    if (token ~ /^[0-9]+:/ && token ~ res "@") {

                        id=token
                        sub(/:.*/, "", id)

                        mode=token
                        sub(/^[0-9]+:/, "", mode)

                        split(mode, p, "@")
                        rate=p[2] + 0

                        diff=rate-target

                        if (diff < 0)
                            diff=-diff

                        if (diff < best_diff) {
                            best_diff=diff
                            best_id=id
                        }
                    }
                }

                if (best_id != "") {
                    print best_id
                    exit
                }
            }
        '
    )
fi

# ------------------------------------------------------------
# Verify that a mode was found.
# ------------------------------------------------------------

if [ -z "$MODE_ID" ]; then

    echo "ERROR: Could not find ${WIDTH}x${HEIGHT}@${FPS} mode."
    echo
    echo "Available virtual monitor modes:"
    kscreen_output | sed -n "/${OUTPUT}/,/^Output:/p"

    exit 1
fi

echo "Using KScreen mode ID: ${MODE_ID}"

# ------------------------------------------------------------
# Apply the mode.
# ------------------------------------------------------------

if ! "$KSCREEN" \
    "output.${OUTPUT_ID}.mode.${MODE_ID}"; then

    echo "ERROR: Failed to configure ${WIDTH}x${HEIGHT}@${FPS}."
    exit 1
fi

echo "Configured ${WIDTH}x${HEIGHT}@${FPS}"

exit 0

IMPORTANT

Change:

PASSWORD="CHANGE_THIS_PASSWORD"

to your own KRFB password.

Do not use the password from this Reddit post.

STEP 3 — Make the script executable

chmod +x ~/.local/bin/sunshine-vm-dynamic.sh

Check the script before running it:

bash -n ~/.local/bin/sunshine-vm-dynamic.sh

There should be no output.

STEP 4 — Test the virtual monitor

The script accepts:

WIDTH HEIGHT FPS

For example:

~/.local/bin/sunshine-vm-dynamic.sh 1920 1080 60

Then:

~/.local/bin/sunshine-vm-dynamic.sh 1920 1080 120

You can also test:

~/.local/bin/sunshine-vm-dynamic.sh 1280 800 90


~/.local/bin/sunshine-vm-dynamic.sh 1280 800 120


~/.local/bin/sunshine-vm-dynamic.sh 1920 1200 60


~/.local/bin/sunshine-vm-dynamic.sh 1920 1200 120


~/.local/bin/sunshine-vm-dynamic.sh 2560 1440 120


~/.local/bin/sunshine-vm-dynamic.sh 3840 2160 60


~/.local/bin/sunshine-vm-dynamic.sh 3840 2160 120

And even:

~/.local/bin/sunshine-vm-dynamic.sh 1920 1080 240

If the requested refresh rate doesn't already exist, the script uses:

kscreen-doctor output.<ID>.addCustomMode.<width>.<height>.<refresh>

For example, 240 Hz becomes:

240000 mHz

The important part is that the script doesn't assume that 120 Hz is the maximum.

STEP 5 — Verify the virtual monitor

Run:

kscreen-doctor -o

You should see something similar to:

Output: 1 Virtual-sunshine-vm
        enabled
        connected
        Modes:
            1:1920x1080@60.00
            2:1920x1080@119.93
            3:1920x1080@239.XX

The exact mode numbers and refresh-rate values will vary.

For example, KDE may report:

119.93

instead of:

120

That is normal.

Likewise, a requested 90 Hz mode may appear as:

89.89

The script intentionally allows a small refresh-rate difference when selecting a mode.

STEP 6 — Sunshine configuration

The important difference from my original guide:

There is no "Force Capture Method" step in this setup.

Do not look for a "Force Capture" option and don't add one just because an older version of this guide mentioned it.

The dynamic script is responsible for creating and configuring the virtual monitor.

Configure the script as the Sunshine preparation command used when a client connects.

The script already understands Sunshine's client environment variables:

SUNSHINE_CLIENT_WIDTH
SUNSHINE_CLIENT_HEIGHT
SUNSHINE_CLIENT_FPS

Therefore, when Moonlight requests a particular resolution/FPS, Sunshine can pass that information to the script.

For example, a client request can result in:

SUNSHINE_CLIENT_WIDTH=2560
SUNSHINE_CLIENT_HEIGHT=1440
SUNSHINE_CLIENT_FPS=120

and the script effectively performs:

2560x1440@120

without you hard-coding 2560×1440 into the script.

STEP 7 — Why this is better than the old version

The old setup was essentially:

1920x1080
      +
120 Hz

Everything was hard-coded.

The new setup is:

Moonlight request
       │
       ▼
Requested width
Requested height
Requested FPS
       │
       ▼
Dynamic script
       │
       ├── KRFB resolution
       ├── KScreen mode detection
       ├── custom mode creation
       └── automatic positioning

So the same script can handle:

1280x800 @ 60
1280x800 @ 90
1280x800 @ 120

1920x1080 @ 60
1920x1080 @ 90
1920x1080 @ 120
1920x1080 @ 240

1920x1200 @ 60
1920x1200 @ 120

2560x1440 @ 60
2560x1440 @ 120

3840x2160 @ 60
3840x2160 @ 120

You don't need a separate script for each resolution.

STEP 8 — Automatic monitor positioning

One problem with the earlier version was that after creating the virtual monitor, part of the display could overlap the physical monitor.

The new script fixes this automatically.

It examines the current KScreen geometry:

Geometry: X,Y WIDTHxHEIGHT

It finds the rightmost physical display and calculates its right edge.

Then it places the virtual monitor there:

physical monitor
        │
        │
        ▼
┌───────────────────┐ ┌───────────────────┐
│                   │ │                   │
│ Physical monitor  │ │ Virtual monitor   │
│                   │ │                   │
└───────────────────┘ └───────────────────┘

There is no hard-coded physical resolution in this calculation.

This is important for systems with different monitor layouts.

STEP 9 — Start it automatically

Once manual testing works, the script can be connected to your Sunshine startup/client preparation workflow.

The important part is that the script should be executed as the user running the KDE Wayland session.

It needs access to:

XDG_RUNTIME_DIR
WAYLAND_DISPLAY
KScreen
KWin
KRFB

Do not run the virtual-monitor configuration as a normal system service without access to the user's Wayland session.

STEP 10 — Check the logs

If something doesn't work, first run:

kscreen-doctor -o

Then run the script manually:

~/.local/bin/sunshine-vm-dynamic.sh 1920 1080 120

The output is very useful.

For example:

Dynamic Desktop: 1920x1080@120
Virtual monitor output ID: 1
Positioning virtual monitor at 5405,0
Virtual monitor positioned automatically.
Checking for 1920x1080@120 Hz...
Using KScreen mode ID: 2
Configured 1920x1080@120

If a mode doesn't exist:

Checking for 1920x1080@240 Hz...
No 1920x1080@240 mode found.
Adding custom 1920x1080@240 Hz mode...
Using KScreen mode ID: 10
Configured 1920x1080@240

That means the script successfully created the missing mode.

STEP 11 — Test with Moonlight

Open Moonlight on your client.

Connect to your Sunshine host and start the desktop.

Try different resolutions and refresh rates.

For example:

1920×1080 @ 60
1920×1080 @ 120
2560×1440 @ 120
3840×2160 @ 60

If your client exposes 90 Hz or 240 Hz:

1280×800 @ 90
1920×1080 @ 240

can also be tested.

The virtual monitor should automatically change to the requested configuration.

Troubleshooting

Virtual monitor isn't created

Check:

krfb-virtualmonitor --help

and:

kscreen-doctor -o

Make sure you are running KDE Wayland.

The requested mode doesn't exist

Run:

kscreen-doctor -o

The script should automatically create a custom mode when necessary.

For example:

No 1920x1080@240 mode found.
Adding custom 1920x1080@240 Hz mode...

is expected.

KDE reports 119.xx instead of 120

This is normal.

For example:

119.93 Hz

is the mode corresponding to the requested 120 Hz refresh rate on this setup.

The script accounts for this small difference.

KDE reports 89.xx instead of 90

Also normal.

For example:

89.89 Hz

can be the actual reported mode for a requested 90 Hz mode.

Displays overlap

The current script automatically calculates the position of the virtual display.

Run:

kscreen-doctor -o

and look for:

Geometry:

The script uses the physical display geometry rather than assuming a particular resolution.

Sunshine cannot see the virtual display

First check:

kscreen-doctor -o

You should see:

Virtual-sunshine-vm

Then make sure Sunshine is running inside the same KDE Wayland user session.

Final result

The finished setup looks like this:

                 KDE Plasma / Wayland
                         │
                         ▼
                 KRFB Virtual Monitor
                         │
                         ▼
                 Virtual-sunshine-vm
                         │
              ┌──────────┴──────────┐
              │                     │
        Dynamic resolution     Dynamic refresh
              │                     │
        1280×800              60 / 90 / 120
        1920×1080                  240
        1920×1200
        2560×1440
        3840×2160
              │                     │
              └──────────┬──────────┘
                         ▼
                      Sunshine
                         │
                         ▼
                      Moonlight

Notes

This setup is specifically for KDE Plasma Wayland using KRFB's virtual-monitor functionality. KRFB creates the compositor-level virtual output, while KScreen controls its modes and geometry

If you are using a different desktop environment, X11 instead of Wayland, or a different virtual-display implementation, the commands in this guide may not apply.

These steps written with the help of chatgpt because I can't find anything related to virtual monitor on Linux and I tried alot of steps didn't work out well and then I found this post

https://discuss.kde.org/t/how-to-create-a-virtual-monitor-display/2725/13

And there is alot good suggestion provided by other users and after alot of trial and error I manage to start sunshine using virtual monitor instead of physical monitor and without using any physical display port I.e., when using edid method hope it will help someone

It just keeps getting stuck on connecting for me. I've tried turning off my firewall, I've tested my connection through other devices and it's totally fine, it's just the Miyoo

I stream my host pc using Apollo and use my rog Xbox ally to connect to it. I have a virtual display set up for my ally. When I stream to my Ally the quality seems and feels good with little to no latency (my host pc is on Ethernet. But when I output it to my living room tv (4k lg tv) the image looks incredibly dark and murky. This is also after setting my Xbox ally’s display, and virtual display to 4k at 60hz. There is also horrible ghosting as well.

Anyone able to solve this issue? Really want to play PC games on my Miyoo :')

Pretty much the title, I’ve tried every hot fix I can find, I’ve messed with my firewall, my wifi setting, made sure they’re paired to the same wifi. Nothing works, even when manually inputting the IP address. Anyone have any ideas? On steam deck in case that matters.

and using windowkey button just takes me out of moonlight app. thanks

Hi, Can anyone Help please?

I'm using a Redmi Pad 2 11" (4GB RAM) as an Artemide 0.5 client.

My host PC is running the latest version of Vibepollo with the following specs:

Ryzen 5 3600

16GB RAM 3200MHz

RX 6600M

Aorus B450M Motherboard

After a system update on my Redmi Pad 2, both the network latency and decoding latency spiked drastically, even on my local network. (I did find out that switching to the H.264 codec brings the decoding latency back to the original 12-15ms).

Can anyone help me fix this?

Anyone interested?

Ever since being shadowbanned, I have been hoping to find a way to interact with users on this platform. It has been a while since the last post was shared on Reddit through community contributor u/nokerb, and I have some updates and news that I would like to share with VoidLink streaming users.

- Apple is deprecating iOS 12, iOS 13, and iOS 14. Since release, VoidLink has maintained the same system compatibility as moonlight-iOS, meaning support for iOS 12. However, later this year and next spring, possibly even earlier, VoidLink may have to drop support for iOS 12 through iOS 14. The situation is as follows:

Please note, however, that does not mean moonlight-iOS will also be forced to raise its minimum system requirement. On the contrary, I believe moonlight-iOS will not face this issue.

VoidLink has recently received several major updates, and I hope users can upgrade and try them as soon as possible:

- Global controller navigation that covers more than 95% of operations for gamepad streamers. I specifically made compatibility adaptations for this feature across iOS 13 through iOS 27.

- High-performance frame generation streaming implemented through an iOS 26+ system API. In testing, an iPhone 13 Pro with the A15 chip running iOS 27 can achieve 60 -> 120 FPS frame generation streaming with intermediate frames at 1344×624, with native HDR support.

- DualSense controller support completed together with Sunshine-Foundation, including adaptive triggers, haptic feedback, touchpad passthrough, and motion sensor passthrough. Although the haptic vibration experience cannot fully match DualSense USB passthrough directly to a PC, it is still better than traditional rumble. You may also want to try setting the Haptic Engine to Built-in. The iPhone’s own vibration motor might be a pleasant surprise.
Special thanks to Sunshine-Foundation for their strong support. In fact, I have long been a community member and important partner of Sunshine-Foundation.

- Thanks to chrisnch@GitHub for decoding the private vibration protocol of the GameSir G8+ MFi controller and contributing a PR to the VoidLink project. The G8+ MFi is one of the few low-latency USB-C direct-connected telescopic controllers available for iOS, with a joystick polling rate between 250 and 330 Hz. Interestingly, GameSir’s official controller testing app requires Bluetooth to make this controller vibrate, while VoidLink only needs a direct USB-C connection.

- Regarding tvOS, I have heard the community’s feedback. I will be doing some related experiments and evaluations soon.

Finally, the previous post about VoidLink’s performance breakthrough:

https://www.reddit.com/r/MoonlightStreaming/comments/1rwptkg/voidlink_has_announced_a_performance_breakthrough/

led to some debate, and even some seemingly unpleasant skepticism, especially around the question of how streaming performance could possibly improve without Metal rendering. I would like to respond to that here:

- Why “standard rendering” matters:

Metal rendering certainly has excellent performance, but HDR rendering with Metal requires developers to implement custom shaders, and it cannot fully reproduce the HDR accuracy of Apple’s standard video processing pipeline. If you know how much effort many third-party projects, such as mpv-player/mpv, have spent studying Apple’s HDR tone mapping without being able to master it, it becomes easier to understand why Apple’s black-box standard video pipeline is an important asset for streaming.
What VoidLink does is significantly improve streaming smoothness and performance without giving up that asset.

Once again, thanks to u/andygrundman and u/mesnigan. Without their earlier work, I would not have been able to complete this improvement.

- This time, I prepared an even crazier video demonstration:

120 FPS Game Streaming for 17 Minutes Straight on iPad Pro 2018 (A12X SoC)

https://youtu.be/vHUg0ikPZvs?si=HK7gPFUUvl9-DD_m

This video was recorded using an iPhone camera in 120 FPS slow motion. Since YouTube only supports uploading and playing videos at up to 60 FPS, I set the video to play at 0.5x speed, starting from 00:43, so that every frame of the entire streaming session can be preserved.

During the 17-minute 2388×1668@120 FPS SDR game streaming session, aside from occasional minor stutters caused by game-rendering FPS drops shown by RTSS in the top-left corner, the video is almost completely smooth. For the A12X, an 8-year-old SoC, I think this can reasonably be called a miracle.

If you are interested in examining the streaming smoothness through this YouTube video, please avoid playing other videos at the same time, and make sure to watch it in fullscreen at 60 FPS.

Que tablets baratas recomiendan para usar con moonlight (apollo/artemis para ser exactos). Busco que sea de 8 pulgadas más o menos para usar con un joystick plegable.

Por ahora me plantee la Samsung A11 o la Alldocube 60 mini turbo

Me preocupa más que nada el tiempo de decodificación de estás.

Alguno que las tengo o haya tenido y probado que tal va, le agradezco su experiencias

I've been spending all morning to try and fix this error and now I'm at a complete loss.

My computer is wired through strong ethernet (1gb/s but normal uses 600-800 mb/s and my TV (Philips oled, running on android TV) is running very well on Wifi under other circumstances like streaming 4K videos through Netflix for example.

I learned that my ISP does not offer the option to connect both within the local network and I tried fixing that with the ZeroTier one option following the troubleshooting. It does seem to work a little bit, I've managed to mirror the pc screen, but I am still mostly getting a black screen saying my connection to pc is slow and to lower the bit rate.

I am using Apollo on my pc and can switch to Sunshine if that would make a difference, but otherwise I'm unsure what to do at this point.

Edit: I don't know if this was the only thing but I switched to Vibepollo and everything works fine now. I might even try and upscale the connection for sharper image. Even online games have no lag.

Shoutout to all the helpful advice for not so tech savvy people like me

Basically I use have a use case for Artemis where I may frequently want to enable and disable the Artemis full keyboard. Doing this on mobile is pretty inconvenient though when you have to use 4 fingers. Is it possible to change that behavior somehow to 3 finger tap opens the full keyboard and 4 finger opens the soft keyboard instead?

I have been using Moonlight/Sunshine to stream from my PC to my iPad Air with no issue for 2 months. But yesterday for seemingly no reason I started getting these weird media lags.

The moment my iPad connects with Moonlight, the media/videos/twitch streams on my PC just stop and stutter the entire time it's connected. The audio also turns into an almost underwater constant stutter. The video gives you an idea of what it sounds like.

I've read a few different threads and checked on their discord, but no luck. I've tried

Turning off Bluetooth.

Turning off location.

Turning off airdrop.

Updating and rolling back Sunshine.

Rebooting.

Going into my router and changing the wifi channel to 149.

Nothing has worked for me.

Is there some kind of fix that I'm overlooking?

I don't understand the sudden change.

Any guidance would be appreciated, thanks. :(

FIXED: I turned off Airdrop receiving and it immediately fixed the stuttering. I guess AirDrop is constantly pinging every half-second in the background which causes the stutter.

When I connect to my PC via my MacBook Air M1 via Apollo I’m consistently getting this weird frame stutter every half-second.

I’ve tried:

turning off promotion on the MacBook, limiting it to 60fps on both the pc and MacBook instead of 120

turning on and off v sync, turning off g sync

Setting identical resolutions

using different codecs (h264, h265)

Using windowed vs fullscreen

Trying artemis instead of moonlight

Different bitrates both low & high

Ethernet in host pc

I have gigabit internet and have done remote streaming flawlessly in the past on other devices so idk whats going on

Pc specs: RTX 5070, Ryzen 9 9600x, 16GB DDR5 ram

Ever since the latest Nvidia drivers all of my custom resolutions on vibepollo fail when I try to connect it just crashes anybody else experiencing this?

I have a windows 11 pc im using to stream my new steam machine too, and im trying to figure out how to use the mic on my pc, to use for games on the steam machine. Ive tried VBAN but i couldnt get it to work on the linux/steam machine end. So does anyone got any suggestions?

Hey everyone,

Trying to build a dual-use streaming setup with Sunshine/Moonlight on Windows, but DisplaySwitch.exe keeps completely breaking my monitor layouts.

My Goal:

• At Home: Keep my physical desk monitor on, but Extend to my 1x MikeTheTech Virtual Display Driver (VDD) so my laptop acts as a true 2nd monitor.
• Outside: Stream my physical primary monitor directly (turn off/ignore the virtual screen).

The Problem:
When launching the "At Home" profile via DisplaySwitch.exe /extend, Windows completely panics. It:

1. Forces the virtual display to become the Primary screen.
2. Disconnects my physical monitor entirely.
3. Resets/wipes out my custom resolutions and refresh rates back to 1080p 60Hz.

Leaving global Display IDs blank in Sunshine doesn't fix it.

The Question:
Since DisplaySwitch is wiping my settings, how are you guys handling this? Are you using specific CLI tools like Vanish, DisplayMagician, or MonitorSwitcher to force Windows to remember custom layouts/resolutions?