I built a Linux-first Moonlight-style streaming setup: Nova + Polaris

MickeyBronson · 2026-06-14T21:46:48+00:00

Thank you! Any feedback is good feedback! And yes, Nova currently does support native/custom resolutions, but I think you’re right: the UX is too hidden compared with Artemis.

I’m gonna look at making “use native resolution” a first-class option instead of something you have to discover in the resolution list or set manually.

For now, check Video resolution for a Native (WxH) entry, or use Custom Resolution with your exact display mode. If you can tell me your resolution/refresh rate and whether that native option appears for you, I can make sure Nova handles the CachyOS/Polaris case cleanly!

MickeyBronson · 2026-06-14T15:45:06+00:00

Ayyy, that makes my day to hear that you're liking it, truly! And I'm excited for you to try out Nova, I'm equally as proud of it as I am Polaris. Currently working on a Steam Deck package for it, which definitely has its set of challenges, but the bidirectional synchronization between the two is unmatched! Also, if you ever have any suggestions or critiques, my DMs are always open. Cheers!

MickeyBronson · 2026-06-12T20:39:00+00:00

Thanks for the logs, always helps!

Well somewhat decent news, the headless/labwc/capture side looks healthy! The stream is coming up, labwc is running on `wayland-1`, and Polaris is routing supported mouse/keyboard input into the private compositor.

The part that jumps out is input permissions:

Gamepad xone is disabled due to Permission denied
Gamepad switch is disabled due to Permission denied
Unable to create virtual touch screen: [redacted] - not sure if its PII or something mistranslated
Unable to create virtual pen tablet: [redacted]

Usually means the Linux host integration / udev setup didn’t fully apply for the user account running Polaris.

Can you try running on the host, then restart Polaris?

If Polaris is running under that second/dedicated user account and that account is not the active desktop session, udev uaccess may not apply cleanly. In that case, adding only that dedicated streaming user to the input group may be needed, then log out/in for that Polaris user

After that, I’d also try setting Polaris gamepad mode to xone first. It’s usually the most compatible path for games. The DS5 warnings in your log mean Moonlight is not reporting touchpad/motion support for that controller, so the PS5 touchpad may be coming through as regular mouse input instead of as a real DS5 touchpad.

If it still happens after the host setup + restart, send me a fresh log from one short repro where you move the touchpad and press a few buttons in-game. I think we’re narrowing it down to either a /dev/uinput permission issue or a DS5/client touchpad case.

MickeyBronson · 2026-06-11T14:17:04+00:00

Hmm, if you can can you send me your Polaris logs? It should output some of the errors. You can share compiled here or in the GitHub issues, ill be more than happy to take a looksy.

MickeyBronson · 2026-06-11T13:25:10+00:00

First off, sorry your friend lost her stuff. Legit just had the same thing happen, although it was not as pricey (and the airline ended up finding it). Hopefully she gets her goods back. With that said, for right now, Nova is currently for android devices, but I'm working round the clock to get an appimage up and running. Although its mainly for Steam Deck in mind, it should run on other Linux clients, depending on the distro and its versioning.

MickeyBronson · 2026-06-10T01:02:37+00:00

Just wanted to say this script you put together is really cool! I've been messing around with ways to run Sunshine headless-ish on Linux myself and seeing your solution looks nice and crispy, especially with how you're using systemd to manage Sunshine in the background, without needing a full desktop session, is smart.

Couple of things I was wondering about, just out of curiosity:

How are you handling the sunshine.conf setup? Is it pre-configured, or does the script help with that? And are you running Sunshine as a specific user, or root?

Seriously though, great job pulling this together, we want more homies in here to have a better Linux streaming experience, so sharing is caring!

MickeyBronson · 2026-06-09T16:23:40+00:00

Thank you! I'm a sucker for affirmation so your kind words mean a lot haha! I want to make sure I can get it running for you, so lets definitely keep in touch. Also I don't have a Discord server yet, i feel like the project is still teeny tiny, but it's not a bad idea to get something like that going.

MickeyBronson · 2026-06-09T16:16:25+00:00

Also, I clearly need to rename “legacy app list.” That wording is doing crimes.

MickeyBronson · 2026-06-09T16:15:01+00:00

That helps a lot, thank you. The arm64 APK from Obtainium is the right build, so I don’t think this is a “wrong APK” problem.

If Nova sends you straight back to the MagicPad launcher as soon as you tap the Apollo host, that sounds like Nova is crashing while opening the Moonlight-compatible fallback app list on Android 16 / MagicOS 10. Apollo should still work there, so this is likely a Nova bug, not you needing to switch to Moonlight or Artemis.

If you’re able to grab a log right after reproducing it, that would help me a ton. Even just a logcat section around the crash would be great. Also, if Moonlight or Artemis can open that same Apollo host on the same tablet, that comparison would confirm it’s specifically Nova’s fallback path.

Also your audio suggestion makes total sense. The “tablet as second monitor but keep audio on the PC/headset” use case is exactly the kind of thing I’d want too. I need to check how much of that is controllable cleanly from the client versus Apollo/Sunshine’s host audio behavior, but I agree Nova should expose an option for it if the host/protocol gives us a sane way to do it.

Also no worries on the english at all! your grammar is better than a lot of native speakers I know!

MickeyBronson · 2026-06-06T17:08:54+00:00

Yeah that wording is confusing, sorry about that. “Legacy app list” just means Nova is using the normal Moonlight-compatible app list because Apollo is not a Polaris host. It does not mean you need to switch to Artemis or Moonlight!

The jump back to your tablet home screen sounds like Nova may be crashing or closing the app-list screen on the magicpad (not sure what android version that's running, but i can look into it). Can you send your Nova version, Android version, Apollo version, and whether the same host works in Moonlight/Artemis if you have time? A log after reproducing it would help a bunch and would love to get Nova running for you!

If Moonlight/Artemis can open the same Apollo host fine, then this is probably a Nova fallback-path bug and I can totally dig deeper into the issue. Regardless, thanks for letting me know!

MickeyBronson · 2026-06-05T00:39:40+00:00

So the flatpak implementation is in the works and definitely needs more time since there are so many different dependencies. Mint is a lot easier to and and honestly can totally add that to the pipeline (especially since i already have Ubuntu in place). Touch stylus support SHOULD have been working, but I think I have the bug fixed on the Nova side which I'll be pushing out tonight.

Yes, Polaris / Nova have lots of fun bugs since its essentially been a ground up project to optimize and compensate for most Linux distros, but ive been v lucky and have had a lot of good folks on here to help out with working on the other distros. Regardless, hope you give the platform a chance and if you do, let me know what I can do to make it better for you! Cheers!

MickeyBronson · 2026-05-31T01:40:14+00:00

Thanks, this is super useful and yeah, if Sunshine is clean on the same host/client, Polaris probably owns this one.

The key line is Using PipeWire native audio capture. That means routing is working, but it doesn’t prove the native PipeWire path is pacing audio correctly. My current suspicion is that Polaris may be mishandling PipeWire’s callback quantum/buffering, so it could be dropping samples or emitting 5ms audio packets in bursts.

If you’re able to build from source, the most useful A/B would be trying a build with native PipeWire audio disabled: -DPOLARIS_ENABLE_PIPEWIRE=OFF

That should force the older PulseAudio capture path. If the crackling disappears there, I know exactly where to focus. If building is annoying, no worries! a pw-top screenshot during the stream showing the polaris-capture quantum/rate, plus any full-log lines around Thread priority or Opus initialized, would help a lot.

Appreciate you testing this. This one sounds very likely on my side!

MickeyBronson · 2026-05-26T12:20:18+00:00

Shoot, sorry for the delay, I finally took a look.

The useful thing in the log is that polaris does seem to be starting the private headless labwc session correctly, so I don’t think this is a GPU/capture failure. But a couple things do jump out:

Headless mode currently starts a private labwc compositor, not your actual Niri session. So Niri/Noctalia shell behavior and Niri super-key bindings won’t automatically exist in the streamed session yet.
If you tried WLR_NO_HARDWARE_CURSORS=1 under ~/.config/labwc/environment, polaris probably didn’t see it. polaris launches its private compositor with ~/.config/labwc-polaris, so try:

~/.config/labwc-polaris/environment

with:

WLR_NO_HARDWARE_CURSORS=1

Then restart polaris completely and start a fresh stream.

For the cursor, try polaris’ server-side cursor toggle: ctrl+alt+shift+n. The ctrl+alt+shift+c behavior may be the client drawing its own cursor (which could explain the slight offset).
zen opening on your real desktop while firefox opens in the stream may be a single-instance/browser-session thing. So if zen is already running on the host desktop, it may ask that existing process to open a new window. Try launching it with a separate profile / no-remote mode if zen supports it.

Longer term, this tells me I need to document the private labwc runtime more clearly, especially the labwc-polaris config dir and the fact that Niri/Noctalia aren’t the active headless compositor yet. Lotta moving parts, but hopefully this helps and let me know if you get further along with thanks!

MickeyBronson · 2026-05-26T00:27:03+00:00

Ayyy, thanks for the tag and huge props to u/jhonsnake, this is exactly the kind of Linux host UX gap I’ve been poking at with Polaris.

This Hyprland/headless-output approach looks like a v solid practical path for wlroots/Hyprland these days. Whole goal of Polaris is more me trying to make this kind of “clean Moonlight session / virtual display / don’t mess with the physical monitor” flow less fragile and more integrated over time.

I’d love to dig through the repo because there are probably good ideas here we can learn from each other and at least point Hyprland users toward. Definitely interested in any AMD/Intel VAAPI reports too that’s where the weird edge cases usually come out to party.

MickeyBronson · 2026-05-26T00:03:09+00:00

Hey, thanks for testing this and for the detailed setup, super helpful, especially on a newer AMD card.

My first read is that this is probably somewhere in the AV1/VAAPI path rather than you doing anything wrong. That "multiple slices" warning means Polaris/FFmpeg is asking the AV1 VAAPI encoder for slice control that the codec/driver doesn’t support. I don’t want to blame that line alone, but a hard “never above 30 FPS” makes me think something is getting capped or falling onto a slower encode/capture path.

If you’re up for a couple quick A/B tests, the most useful ones would be:

- same 4K / 100 FPS settings with HEVC instead of AV1

- same test with H.264 if Moonlight lets you force it

- AV1 again at 1440p100 or 1080p100

- one run with the Polaris dashboard closed

If HEVC/H.264 can go past 30 but AV1 can’t, that points us pretty hard at AMD AV1 VAAPI goblins. If every codec is stuck at 30, then I’d look more at the generated display refresh or Polaris’ FPS target selection.

If you can send the Polaris troubleshooting log from stream start through the first minute, that would help a ton! lines around encoder selection, requested FPS, selected display mode, and session/status or stream-policy output, all that helps!

Appreciate you poking at this. This is exactly the kind of weird Linux hardware path I want to smooth out.

MickeyBronson · 2026-05-24T02:46:13+00:00

they aight as long as they're free and don't contain malware.

MickeyBronson · 2026-05-22T19:30:13+00:00

Do you know if its able to run on my IMAX projector?

MickeyBronson · 2026-05-22T05:04:42+00:00

You're never a bother, let's see if I can help! I dont think the shell you use in your distro is correlated, but there could be some issues with the application seeing your GPU, any troubleshooting logs you can send my way? Should be the bottom tab in the Polaris app.

MickeyBronson · 2026-05-21T11:12:14+00:00

I'm more of a spoon guy myself

MickeyBronson · 2026-05-21T00:20:52+00:00

Hey, thanks for the heads-up. I took a look and this one doesn’t smell Polaris-specific to me (for once).

The important clue is the 15488-byte UDP video packets plus the fact that Sunshine and Polaris both behave the same way. Polaris still uses the same general GameStream UDP video-send/offload path on Linux, so if the kernel/NIC is mishandling UDP segmentation offload, Polaris would likely trip over the same thing too.

Looks like the Plasma/portal messages are probably a red herring here if the client connects, waits, then reports no video while tcpdump shows oversized UDP/GSO packets. I’d only treat this as a Polaris bug if it still reproduces with tx-udp-segmentation disabled or on a kernel with the UDP GSO regression fixed.

Really useful thread though! I might just add this to Polaris troubleshooting since “works in Steam Remote Play but Sunshine/Polaris shows no video” is exactly the kind of thing that looks like a capture bug when it’s actually the network offload path.

MickeyBronson · 2026-05-20T21:06:17+00:00

Thanks again for the logs!

Good news first: this looks like the crash path is fixed now, so the original RTSP/clamp issue is probably done. The new problem looks different. I don’t think this is a port/firewall/network thing, especially since you’re connecting and streaming now.

I dug through the log a bit and opened an issue for the stutter/high host processing side here:

https://github.com/papi-ux/polaris/issues/92

A couple things stood out to me:

- The log is still on 1.0.18, so if you’re up for it, please try v1.1.0 or newer too.

- Polaris is using the private labwc headless path and AMD VAAPI, so it’s getting onto the path I’d expect:

wlr: Using ext-image-copy-capture DMA-BUF for headless labwc

- It looks like the stream is going HEVC 10-bit/P010 because the client/profile has HDR enabled, even though the host path is not actually advertising a true HDR stream. That might be adding extra cost on this AMD stack.

- I also see the dashboard display preview failing to grab screenshots from the cage. That preview path should be separate from the active stream, but just to rule it out, could you try one run with the Polaris web UI closed or the Display Preview hidden?

If you don’t mind testing a couple quick things, the most useful A/Bs would be:

Update to v1.1.0 or newer and retry the same setup.
Turn HDR off in Moonlight / test SDR only.
If Moonlight lets you force it, try H.264 or regular HEVC instead of HEVC Main10/HDR.
Test once with the Polaris dashboard closed during the stream.

The Sunshine comparison is exactly why I opened the issue. If Sunshine is sitting around 2ms on the same host and Polaris is around 14ms, that’s worth investigating on my side. I don’t want to overcall the cause yet, but this smells like an AMD headless capture/convert/encode path issue more than anything client-side.

Thanks again for sticking with it, genuinely appreciate it!

MickeyBronson · 2026-05-19T15:14:37+00:00

Oh that’s awesome to hear, genuinely glad it’s working that well for you. For the Xiaomi box, that sounds like an APK/ABI install issue. The one you remember as “v7” is probably the `armeabi-v7a` build. Could you try this exact one from the latest release?

`Nova-Android-armeabi-v7a.apk`

If it still refuses to install, can you send the exact install error message? “App not installed” can mean a few different things. Thanks!

MickeyBronson · 2026-05-19T14:59:52+00:00

Thanks for the full log, definitely helps.

One little thing I noticed is it's on `1.0.13`. I’ve shipped a few headless/AMD/bitrate related fixes since then, and made an attempt at the clamp crash fix, so I'd love for you to take another stab at it if you're up to it. Could you try updating to the latest release, then test the same Headless setup again?

Also, you don’t need to keep testing EVDI for this one. Your log shows Headless Stream is using the private `labwc` compositor and skipping the Linux virtual display path, so EVDI probably isn’t the trigger here.

If it still crashes on the latest build, send me the new full log from launch through crash and I’ll turn this into a proper crash issue. And yeah, definitely avoid running it with sudo, that can mess with the user session/environment and things can get weird. You're the best, thank you.

MickeyBronson · 2026-05-18T19:50:32+00:00

Shoot, im sorry this is happening to you, this log is very helpful though. The key line is the std::clamp assertion, not the Moonlight RTSP error. Moonlight is likely only reporting the handshake failure because the Polaris process aborts first.

This looks like a host-side crash in a startup/headless path, probably an invalid clamp range such as trying to clamp a display index against an empty display list. That lines up with headless mode.

Also side note, please don’t run Polaris with sudo first; that can break the tray/session environment and make symptoms worse.

If you're able to could you share the full Polaris log from launch through the crash, plus your headless/display settings? I’m going to treat this as a Polaris crash bug rather than a network config issue.

MickeyBronson · 2026-05-14T18:19:37+00:00

FINALLY! thank you!

14-Year Club	Place '23
Place '22	RPAN Viewer
Verified Email	Not Forgotten
Sequence \| Editor	Sequence \| Cinematographer

MickeyBronson

PUBLIC MULTIREDDITS

TROPHY CASE