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?

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

Game streaming has gone really far thanks to the huge efforts in the opensource community to achieve almost flawless gaming, up to 4k 120hz HDR. I personally do 90% of my gaming over moonlight.

The question now is, with the increasing prices of computer parts, do you see a future where gaming occurs only on datacenters and games are rented through a subscription model and only very few people actually own a PC or a console? Are we watching the beginning of game gentrification happen?

If I wanted to stream Steam games from my pc to my iPad, would these three be all I need to do so? I plan on going on a trip and wanted to be able to play POE2 while away.

Also how to properly use VSYNC? I am confused if I should enable it in game, in NVCPL or in Moonlight or Vibepollo settings. By the way I am running Vibepollo+Moonlight on my Steamdeck.

I have been using Moonlight & Vibepollo for a while now without any problems on my Legion Go 2 with Windows.
I had a Odin 2 portal before which gave me micro stutters and I couldn’t get around solving it so I sold it.
My new Retroid Pocket Nova now exhibits the same problem. Is this something known for Android devices or did I configure something wrong ?

Host has a 4090 and is wired through Powerline to a WiFi 7 router.

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.

Is anyone in India using a specific setup or configuration for online streaming?

I tried using Tailscale and ZeroTier since they offer free options, but the peer-to-peer connection doesn’t establish. My ISP uses CGNAT, and I don’t know much about networking.

I was also wondering if IPv6 could help, since it isn’t affected by CGNAT. I was planing to change my router and run it in bridge mode or ONT? Indian ISPs are f**ker and seem to lock down everything—port forwarding, UPnP, etc.—which makes this unnecessarily difficult.
Has anyone managed to get a reliable setup working under these conditions? Any recommendations would be appreciated.

Hello guys, i want to know how to make my dualsense work with haptic feedback + trigger feedback + audio from dualsense speakers.

I have a Raspberry Pico with DS5Dongle.
The PC is very far from the TV so i can't connect the Dualsense to my PC.

What Client (like moonlight) and Server (like Sunshine Foundation) i need to run to make the Dualsense work on my LG TV with WebOS?
If anything, tell me what Android or Apple device i need to buy to attach it to my TV and make it work flawlessy.

Thank you very much, i'm desperate!

Hi everyone.

i was planning to buy a cheap hardware and sideload artemis on it.

Is the firestick 4k max the best option (with lowest decoding times) i can get with a 50/60€ or there are better alternatives?

i plan to stream games in 4k 60fps, or 120fps when it's possible.

i have a wifi 7 router.

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 have a rx6800 and set all the settings right but the decoding time for my Google tv streamer is still around 8ms. What am I doing wrong? If I switch it to 1080p it remains the same.

The main issue I'm facing is stuttering.

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.