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

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?

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.

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.

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’m currently using tailscale vpn and moonlight to play games outside my home.

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.

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.

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?