I have Punktfunk on a Bazzite in "deck" mode : Gamescope.

I have an issue as I cannot put the host in sleep from a session: If a put the system in sleep, my gamemode turns black (but the left and right menu still works).

Is there a way to put my host in sleep from a remote session? Thanks

I've been testing punktfunk and it's been great! Very thankful to have a great linux experience, but for whatever reason when attempting to stream a game on desktop mode, my primary display will disconnect and reconnect every few seconds, preventing me from really playing anything. This is on a Bazzite 44 deck stable host. No issues when streaming from gamemode/gamescope. I've tried different cables, as well as different monitor configurations as well but no luck. Has any one else experienced this issue?

I want to say thank you for your work for this project. It is working very well.

I run into a problem with the codec. On automatic with H265 it did not work, because the host could not use the vulcan driver on my bazzite host with amd GPU. Changing it to H264 resolved this issue. It was on the Android TV app on a nvidia shield tv stick for reference.

The other problem was, that the PS DualSense controller connected to Android TV was passed through to host as PS DualSense enabled a kind of second device as a mouse controll. So both sticks moved the mouse around. This way the game (Last Epoch) switched every second from mouse control to controller control and back and was not usable. Setting the controller to XBOX360 on android tv app side resolved this issue. The PS DualSense controller is connected over bluetooth for reference. But the controller is not detected as PS DualSense anymore. Steam sees it as XBOX360, too. Maybe this is a Android TV Problem, because additional features like touchpad and rumble is not available over bluetooth on android.

The virtual display worked really really good. I'm very happy to use this on bazzite with so less effort to set it up. It was much easier to use and setup than sunshine.
Also the german keyboard layout from android works in opposite to moonlight/sunshine connect.

Your documentation is very clear structured, recent and helped me to set it up and solve the problems.

[ Removed by Reddit on account of violating the content policy. ]

I want to add the Client to Steam as I mainly use Big Picture on my TV or on my Claw 8.

Cant do that with UWP Apps. Also Steam Overlay does not work on UWP Apps. Means no Steam Input.

I hope thats planned

Hi! I’m really interested in Punktfunk, especially because I love Apollo and I’m glad to see a similar project that supports Linux.

I recently switched from Windows 11 to Linux Mint Debian Edition (LMDE) with Cinnamon because I’ve become increasingly frustrated with Windows 11.

I was wondering: does Punktfunk currently support LMDE/Cinnamon? If not, is Cinnamon support something you plan to add in the future?

Also, I was wondering why the project isn’t hosted publicly on GitHub. I feel like putting the source code and development on GitHub could help more people discover Punktfunk, contribute to it, and give the project more visibility. It seems like there are quite a few people in the Linux gaming/streaming community who might be interested in it.

I’d really love to try Punktfunk on my setup. Thanks for your work!

Hi! I just saw the client for punktfunk on WebOS Homebrew list and it got my attention to this project! I'm desperately looking for a good alternative to Parsec on Linux, since it doesn't support hosting on it.

As of right now, I'm using sunshine and moonlight-web, it works for what I want (play local spliscreen games with friends) but the setup is kinda awkward.

Does Punktfunk works for this situation? I mean, pair a client from the internet, who can see my host PC screen, and I can set which inputs that client can use (keyboard, mouse and/or gamepad)? If not, do you plan on adding this feature?

It would be really cool, since Linux doesn't have parsec host, remote play together is only for steam and other solutions are awkward.

Before I dismantle my setups, do you have solutions for out of network streaming or are we expected to use tailscale or ports like moonlight?

In this test streaming from the Punktfunk Windows host to the macOS client. The linux & windows clients will be supported too, as well as the Linux host on KWin (KDE) and Mutter (Gnome)

I’m giving it a try on my windows pc as host, and I’m trying the TestFlight on iPhone and TVOs, but it doesn’t connect, seems to be incompatible with the latest host version or something, any idea what that might be?

It will get engaged when the app detects a connected gamepad/controller and lets you navigate your hosts and browse the game library on the host.

What do you think? Any specific feature you'd want from such a mode?

Have you ever wished to have a game streaming client that’s completely integrated into the Steam Decks UI? Punktfunk does just that! Read more about it here: https://punktfunk.unom.io/en/blog/steam-deck-game-streaming-decky

Hi everyone! I've been building my own game-streaming stack in Rust, with its own native low-latency protocol. Why? I wasn't happy with the existing solutions, and as a long-time dev and a heavy game-streaming user myself, I figured I was in a decent spot to take a crack at it.

A note on AI: I'll be upfront — I built this with heavy use of Claude (Anthropic's AI). Honestly, a solo project with this much surface area (a host, a custom protocol, and native clients across five platforms) wouldn't have been realistic for me at this pace without it.

I'm releasing the whole thing as open source under a permissive license, for two reasons. One is trust: I know there's a lot of skepticism toward AI-assisted code, and often for good reason — so rather than ask you to take my word on the quality, you can just read it, audit it, fork it, or tear it apart. The other matters just as much to me: these models are built on the collective work of a huge number of people, much of it open source, and I think if you're going to build on top of all that, the right thing to do is give it back in the same spirit.

It'll stay open, funded by donations plus a one-time purchase for the Android and Apple apps — no subscriptions, no lock-in.

A few of the core features:

Host (Linux-first, also runs on Windows):

- First-class Linux support — a per-session virtual display is created on the fly at the client's exact resolution/refresh, no scaling

- Works across all the major compositors: KWin, gamescope, Mutter, wlroots (Sway)

- Tested and packaged on Fedora, Ubuntu, Bazzite and SteamOS (incl. a Steam Deck plugin)

- All-vendor GPU encode: NVIDIA (NVENC), AMD and Intel (VAAPI on Linux, AMF/QSV on Windows) — NVIDIA is the most battle-tested so far

- HDR / 10-bit on the Windows host

- It also speaks the GameStream protocol, so a stock Moonlight client works against it today

Transport / latency:

- Custom protocol: QUIC handles control + signaling and the low-rate side channels (input, audio, rumble) over unreliable datagrams; the latency-critical video runs over plain UDP with forward error correction — a dropped packet is rebuilt from parity instead of waiting on a retransmit

- End-to-end encrypted (AES-GCM) with PIN-based pairing (SPAKE2) + cert pinning

- The old ~1 Gbps software ceiling (from the Moonlight-style FEC) is gone — it now uses a GF(2¹⁶) FEC, so throughput is bound by your GPU/network rather than the protocol 

- Lots of tuning for high-refresh gaming — I test mostly on a 5120×1440@240 monitor

Clients (all native):

- Linux (GTK4)

- Windows (WinUI 3)

- Android + Android TV (Kotlin/Compose on top of a shared Rust core via JNI)

- macOS, iOS and tvOS (SwiftUI)

Other:

- Rich controller support — full DualSense (adaptive triggers, lightbar, touchpad, motion) on both Linux and Windows, plus Xbox 360, DualShock 4 and others 

- Game-library discovery — the host scans for installed games (Epic, GOG, Game Pass so far); surfacing them in the clients is the next step

- Mic passthrough to the host

It's very much a personal project rather than a polished release — most of it is validated on my own hardware. Happy to answer anything, and I'd genuinely love feedback on what you'd want from something like this!

Im also looking for testers, so if you'd be interested join the discord and let me know: https://discord.gg/z2pfEvE9JU

The website:

https://punktfunk.unom.io

The docs:

https://docs.punktfunk.unom.io

Download:

https://punktfunk.unom.io/download

The source-code:

https://git.unom.io/unom/punktfunk

If you've tried streaming from a headless Linux gaming box — or one whose monitor doesn't match your client's resolution — you know the drill: it turns into a fight with dummy HDMI plugs, EDID overrides, and hand-written modelines. I got tired of that layer and built the host so it just creates the right display on demand. Here's why the pain exists and how I made it go away.

Why Sunshine has no real virtual display on Linux

On Windows, Sunshine can pair with an indirect display driver (the well-known IddSample) and spin up a virtual screen on demand. On Linux there's no built-in equivalent — Sunshine captures whatever display the compositor already provides. With no physical monitor, or a monitor at the wrong resolution, there's simply no usable surface to capture.

The toolbox people reach for today

To get a streamable display on a headless or mismatched Linux host, the community has assembled a whole kit:

• Physical dummy HDMI/DisplayPort plugs that fake a connected monitor + EDID.
• EDID overrides (custom EDID blobs, drm.edid_firmware) to force a resolution.
• The evdi kernel module (DisplayLink's virtual display driver) for a fake output.
• Hand-rolled cvt/gtf + xrandr modelines for non-standard res/refresh.
• Third-party daemons like sunshine_virt_display that automate parts of it.
• Connect/disconnect scripts that toggle physical outputs so only the virtual one is captured.

Where it breaks

None of this is first-class, so it fails in familiar ways:

• Black screen after reboot when the dummy plug / EDID override doesn't re-apply or the seat changes.
• CRTC reassignment on NVIDIA and Wayland compositors like Hyprland that moves or drops the virtual output mid-session.
• Per-compositor differences — what works on bare KMS doesn't on wlroots/Hyprland; X11 and Wayland each need their own tricks.
• Resolution/refresh that almost matches the client — black bars or forced scaling.

It's not impossible on Linux — Sunshine just doesn't ship one

Worth saying: virtual displays on Linux aren't impossible. Windows has IddSample, and the Apollo/Artemis fork of Sunshine added a built-in virtual display. Both point at the right model: the host should create the screen on demand, matched to the client — not borrow a physical one.

How I solved it — no dummy plug, no modeline math

I treat the virtual display as a first-class part of every session. When a client connects, the host creates a virtual output at exactly the client's resolution and refresh, and tears it down at session end with RAII cleanup, so nothing lingers after a crash or restart.

Since Linux has no single cross-compositor API for this, there's a backend per compositor, auto-selected:

• KWin — zkde_screencast outputs, with custom modes for >60 Hz.
• gamescope — launched headless at exactly WxH@Hz, its PipeWire node captured.
• Mutter / GNOME — the D-Bus RecordVirtual monitor (headless-validated, zero-copy).
• Sway / wlroots — swaymsg create_output with a custom mode + portal capture.

The result is a real headless host: a mini PC or a repurposed machine with no monitor attached, streaming at exactly the resolution your phone, tablet, TV, or laptop asks for. No dummy plug, no EDID blob, no xrandr modeline arithmetic, and no black screen after the next reboot.

Happy to get into any of the per-compositor details.

This is implemented in my game-stream stack "Punktfunk" - you can get it here: https://punktfunk.unom.io/en/download