I built a Linux CPU boost tool around cpufreq policies
▲ 0 r/linuxadmin+1 crossposts

I built a Linux CPU boost tool around cpufreq policies

I've been working on BoostLock, a small root-only Linux CLI/daemon for keeping CPU boost available during idle periods.

The 0.2.0 release discovers /sys/devices/system/cpu/cpufreq/policy* instead of guessing from CPU model names. Each policy keeps its own frequency limits and effective target, so mixed-capacity systems don't inherit one policy's range. --target auto uses each policy's active upper limit, and numeric MHz requests are clamped per policy.

Before startup changes anything, BoostLock builds the full policy plan and opens every planned write path. If a later write fails, completed writes are rolled back. Controls are capability-driven: a writable boost, EPP, EPB, PM QoS, or cpuidle path is added to the same plan, and an unavailable control is reported as skipped.

I have Intel, AMD, and ARM policy fixtures in the test suite, but I haven't done physical hardware smoke testing across all those drivers yet. If you try it, I'd like to know the CPU, driver, kernel, and what sudo boostlock status --json reports. It needs root and can increase idle power and temperature.

Repo: https://github.com/vindeckyy/boostlock

u/Select_Car9532 — 1 day ago
▲ 3 r/foss

OpenBoxGL is an AGPL-3.0 local game library for Linux

OpenBoxGL keeps game metadata and launcher state in a local JSON library instead of an account-backed service. It imports Steam, Heroic, Lutris, Gameyfin, ROM folders and plain executables, then exposes them through one Linux UI.

The native host starts the local Python server and renders the interface in WebKitGTK. Both the native window and browser mode use the same token-authenticated REST API on loopback. Themes only override shared CSS tokens, and emulator support comes from small YAML definition files.

The project is licensed AGPL-3.0. The repository, AppImage build, Flatpak manifest, tests and parity matrix are here: https://github.com/vindeckyy/OpenBoxGL/

I would value review from people who care about portable local data and inspectable software, especially around import edge cases and packaging.

https://preview.redd.it/ofxt0re3nzjh1.png?width=1920&format=png&auto=webp&s=454002d75ffc3cc0a68384eb58745c863c585b13

https://preview.redd.it/flw0nre3nzjh1.png?width=1920&format=png&auto=webp&s=33a91ff17651601c2e34ac115685d358fc3b9be2

reddit.com
u/Select_Car9532 — 4 days ago

OpenBoxGL puts Steam, Heroic, Lutris and ROMs in one Linux library

I built OpenBoxGL because my games were split across Steam, Heroic, Lutris and a pile of ROM folders. It scans those sources into one local catalog, with search, playlists, metadata, artwork and per-game launch profiles.

Everything stays on the machine. There is no account, cloud service or telemetry, and the library is stored as plain JSON with a backup beside it. The normal library view is built for mouse and keyboard, while Big Box mode is controller-ready for a couch setup.

AppImage and Flatpak builds are available here: https://github.com/vindeckyy/OpenBoxGL/

I need testing from people with mixed libraries. If an importer misses something or controller navigation feels wrong, tell me what setup exposed it.

https://preview.redd.it/af1w7vsmmzjh1.png?width=1920&format=png&auto=webp&s=76c4646c41628c704ead69e04311e48ff5065515

https://preview.redd.it/5l7u6usmmzjh1.png?width=1920&format=png&auto=webp&s=0543904e94a7194676714b2cbbe1725efc566388

reddit.com
u/Select_Car9532 — 4 days ago

I built a LaunchBox alternative for Linux that brings Steam, Heroic, Lutris and ROMs into one local library

I have been daily driving Linux as my main gaming OS for years and I got tired of jumping between Steam, Heroic, Lutris and a folder of ROMs. LaunchBox does a lot of this on Windows but there is no native build and Premium locks a bunch of workflows. I ended up building OpenBox Game Launcher for myself and it has grown past the point where it is just for me.

It is local first. No account, no cloud, no telemetry. Your library lives at ~/.local/share/openbox-game-launcher/library.json and it is schema version 5 with atomic writes and a .bak last known good copy beside it. If the write fails, state_store.py still has the previous file to recover from.

View the website here for more information!

What it brings together:

  • Steam scan, plus Heroic (Epic, GOG, Amazon), Lutris, Gameyfin self hosted, ROM folders, ScummVM, RPCS3, Vita3K, and plain executables. All of it lands in one searchable catalog. Search is in catalog.py, with advanced filters, bulk edits, custom fields, playlists and ordered lists.
  • Emulators through YAML definition packs in emulator_defs/. retroarch, dolphin, duckstation and others are mapped by extension to platform, with startup commands that get tokenized safely. parity_emulator_defs.py builds the launch command, handles single and multi file handling, and you can set per game launch overrides. It also auto detects emulators on PATH and can install or update Flatpak emulators from the UI.
  • Metadata and media from the LaunchBox Games Database. That is the large community DB, covers, backgrounds, screenshots, box backs, spines, 3D boxes, clear logos and more. There are also hooks for IGDB search, Steam and GOG media, EmuMovies and the Bezel Project. Duplicate detection and region priority live in parity_media.py, with queue handling for downloads.
  • Sessions and saves. Play time tracking, history, and save discovery for Steam Cloud, RetroArch, PCSX2, PPSSPP, RPCS3, Dolphin, Cemu and a few others in saves.py and parity_saves.py. Backups are ZIP archives you can make per game or for the whole library through parity_backup.py, with rotation and restore safety checks.

How I run it: the default is a native window. native_host.c spawns web_app.py and renders the same index.html, app.js and app.css in WebKitGTK 4.1, so it feels like an app and not a browser tab. python3 web_app.py still works for the web UI if you prefer. Both hosts speak the same REST API on loopback, authenticated with X-OpenBox-Token.

AppImage is the primary delivery, build_appimage.sh bundles a Python binary and the stdlib so you do not need to chase distro packages. There is also a Flatpak manifest at io.openbox.GameLauncher.yml and a normal sudo make install.

The full capability status with checks is in docs/PARITY.md in the repo. Every row says what is done and what was verified. If you are on Linux and you have a messy mix of launchers and ROM folders, this might clean it up. I am happy to answer questions about setup, import quirks or emulator profiles. Link is https://github.com/vindeckyy/OpenBoxGL and the docs are at https://openboxgl.github.io

Full disclosure: I used AI as a tool to help build OpenBox. All features, file paths and checks above are from the real repo.

u/Select_Car9532 — 4 days ago

OpenBox hit v1.0.0 - Need testers!

More info: here

Repo: here

!!! LINUX ONLY !!!

OpenBox now opens in a native WebKitGTK window by default, rendering the same library UI as the web app instead of a browser tab or the removed Tk interface.

Thanks!

u/Select_Car9532 — 7 days ago

Looking for testers: SolarFlare v1.0.9 (Linux Sunshine fork for Moonlight)

Hey! SolarFlare dev here again.

Looking for Linux people who already stream with Moonlight to try SolarFlare v1.0.9 and tell me what actually feels different on their box. Good, bad, weird compositor bugs, all useful.

SolarFlare is a game streaming host. Same job as Sunshine: capture the desktop or game on a Linux PC, encode it, send it to a Moonlight client. I kept the compatibility pieces on purpose. The binary is still named sunshine, the systemd user service name is the same, config still lives in ~/.config/sunshine, ports stay put, so existing Moonlight pairings should keep working. If stock Sunshine is already installed, uninstall it first or youll fight over the same paths.

Ive been pointing this fork at local LAN use. Host and client on the same network, Linux host, less hitching when the machine is busy. Most of the extra stuff is behind switches in ~/.config/sunshine/sunshine.conf (and some Audio/Video controls in the Web UI) so you can turn pieces off without rebuilding if you want a fair A/B against stock Sunshine.

One place this shows up in the stream path, PipeWire hands frames when they arrive, those frames go into a bounded queue, and if a frame sits in the network send queue too long for the framerate you asked for, it gets dropped and we wait for a fresh keyframe instead of blasting stale pictures at the client. Theres also an optional adaptive bitrate controller that watches packet loss / RTT plus host encode health, pulls bitrate down when the link is messy, then ramps back once things calm down.

On the send side it reads your real NIC link speed (2.5 GbE, Wi-Fi 6/7, etc.) and paces against a percent of that, instead of acting like everything is old 1 Gbps. Bigger UDP buffers help fat 4K streams not stall on send. Optional knobs if you want them: busy-poll the NIC a bit, tag stream packets so a QoS-aware router can prefer them over downloads, pin capture work to a quieter CPU core, and bump the GPU into performance while a session is active (then restore after disconnect).

Audio defaults are still upstream-compatible. PipeWire gets an 8 ms latency hint by default. Optional FX (AGC, voice ducking, noise gate, Opus tweaks) lives in the Web UI Audio/Video tab and starts off. latency_mode = aggressive shrinks the audio capture queue and uses a faster software scaler when software scaling is in play; hardware encode stays the same either way.

Other stuff people keep asking about on Linux hosts:

- Headless backends (labwc, KDE virtual monitor, gamescope, niri)

- Optional virtual display if theres literally no monitor plugged in

- Hermes-KMS as another capture backend if you install that module

- Steam / Lutris / Heroic game scanning from the UI

- Redesigned Web UI

- Update now button inside the outdated version banner in the WebUI for people who already have SolarFlare installed

- Scoped API tokens and trusted-subnet pairing helpers if you automate the host

I personally run AMD gear day to day, so a lot of my own testing is there, but the installer covers Arch/CachyOS, Debian/Ubuntu, Fedora-family, openSUSE, Bazzite, and NixOS. The release Im asking for is Linux x86-64.

Current release: https://github.com/vindeckyy/Solar-Flare/releases/latest

Repo: https://github.com/vindeckyy/Solar-Flare

Site: https://vindeckyy.github.io/Solar-Flare/

Changelog: https://github.com/vindeckyy/Solar-Flare/blob/master/docs/CHANGELOG-SolarFlare.md

git clone --recursive https://github.com/vindeckyy/Solar-Flare.git

cd Solar-Flare

./scripts/linux-install.sh

systemctl --user enable --now app-dev.lizardbyte.app.Sunshine.service

Then open https://localhost:47990

If you try it, dump this in a comment:

- Distro + GPU (AMD/NVIDIA/Intel) + wired or Wi-Fi

- Resolution / fps / codec

- Capture path you landed on (KMS, PipeWire/portal, X11, Hermes, headless, etc.)

- Whether it felt smoother, the same, or worse than Sunshine on the same box

- Journal errors, UI weirdness, pairing issues, audio glitches, mouse/monitor mapping bugs

If something feels off, flip individual SolarFlare knobs back toward upstream in sunshine.conf (or leave Audio FX off) and compare. Thats intentional.

Built on Sunshine. Some of the Linux capture / headless / stream-health thinking was informed by reading Polaris; SolarFlare is still a Sunshine-derived host and that review was design inspiration, not copied project code.

Thanks if you have time to poke at it.

u/Select_Car9532 — 22 days ago

Linux Moonlight host testers needed - SolarFlare v1.0.8 (A/B vs Sunshine)

https://preview.redd.it/60uhk6l5izfh1.jpg?width=1425&format=pjpg&auto=webp&s=5ce937141c7e16451fcdc5c8117d0d3ec0d7cc13

TL;DR: Latency and AMD focused Linux Sunshine fork for Moonlight. Same pairings, ports, ~/.config/sunshine. I've been tightening the host hot path on my AMD/NVIDIA box. v1.0.8 (tag v2026.728.1-solarflare). If you already stream, A/B it against stock Sunshine on the same settings and dump numbers.

https://github.com/vindeckyy/Solar-Flare

https://github.com/vindeckyy/Solar-Flare/releases/latest

https://github.com/vindeckyy/Solar-Flare/blob/master/docs/CHANGELOG-SolarFlare.md

Capture wakes on PipeWire frame arrival instead of phase sleeps. Frames hit bounded queues, and per-session pacing can drop stale ones before encode. latency_mode=aggressive tightens the audio side. Headless without a dummy plug if thats your pain. Extra knobs are all opt-in so nothing weird flips on by default. UI is https://localhost:47990

I dont have a published encode-only ms table. Whole stack, one box. I need other GPUs (RDNA2/3/4/ and APUs especially; Nvidia/Intel still useful), other distros, Deck/gamescope/Bazzite, whatever you actually run.

Back up ~/.config/sunshine. Uninstall stock Sunshine and install like this:

git clone --recursive https://github.com/vindeckyy/Solar-Flare.git

cd Solar-Flare

./scripts/linux-install.sh

systemctl --user enable --now app-dev.lizardbyte.app.Sunshine.service

Keep Moonlight res/fps/bitrate/codec the same as your Sunshine run. Optional second pass with latency_mode=aggressive.

Reply with GPU + driver, distro, capture path that came up, client latency/feel vs Sunshine, wired or wifi. Paste host logs if it freezes, drops frames, or a knob does nothing. Feels-the-same is still useful.

Feature ideas welcome if you say the real setup (headless, Deck living room, dual seat, MoonDeck, gamepads, ...). I'll say if its a small host change or bigger session/input work. No timeline promises.

Already posted on the last thread? Dont retype. New GPU or a clean A/B still helps.

Roast the install script if your distro hates it!

Thanks :-)

reddit.com
u/Select_Car9532 — 24 days ago

I’m building SolarFlare, a Linux-first Sunshine fork for lower-latency Moonlight streaming

Hey everyone,

I’m the developer behind SolarFlare, a custom Sunshine fork for people who want a more tunable Linux host for Moonlight.

Repo: https://github.com/vindeckyy/Solar-Flare

Latest release: https://github.com/vindeckyy/Solar-Flare/releases/latest

Fork changelog: https://github.com/vindeckyy/Solar-Flare/blob/master/docs/CHANGELOG-SolarFlare.md

I’ve been working through the whole host path, from capture to encode to transport to the Web UI. The current fork includes:

- A responsive observatory-style Web UI with a desktop navigation rail, mobile controls, a magnetic-field host dashboard, denser configuration views, a fully local featured-client catalog, shared theme bootstrap, and a keyboard command palette.

- Linux and AMD-first tuning for capture, transport, and host control: adaptive bitrate with recovery mode, link-speed detection, pacing, socket buffers, busy polling, DSCP/QoS marking, rate caps, CPU pinning, GPU governor control, PipeWire latency controls, optional audio FX, and headless virtual display support.

- Headless capture options for labwc, KDE’s krfb virtual monitor, and gamescope on Steam Deck, plus niri/Smithay auto-detection and optional Hermes-KMS capture through DKMS.

- Low-latency encoder controls, including NVENC presets, per-application overrides, Vulkan min/max QP controls, and capture paths for X11, KMS, PipeWire, portals, and headless compositors.

- Better control and diagnostics through scoped bearer tokens, API scopes, trusted-subnet and pairing controls, an HTTP adaptive-bitrate control surface, categorized error counters at /api/errors, and more useful tagged logs.

- Practical reliability fixes: pairing certificates persist across restarts, PIN retries behave better, detached app sessions stay alive, Moonlight stream ports are aligned, audio socket handling is fixed, and X11 touch input works again.

- Easier Linux deployment with distro detection for Arch/CachyOS, Debian/Ubuntu, Fedora, openSUSE, and Bazzite, plus a published Linux x86-64 binary, local-install capability handling, boot-time CPU/NIC/NVIDIA tuning services, clearer build errors, release tooling, and screenshot/test coverage.

- A security pass covering RTSP bounds checks, certificate parsing, TLS handshake limits, password and auth throttling, upload path traversal, log injection, and HTTPS-only downloads.

SolarFlare keeps Moonlight compatibility and the protocol/config identifiers that clients depend on. It is GPL-3.0, and Linux x86-64 is the primary release target.

This is a fork, so the goal is transparency and useful testing. If you run Linux, CachyOS, a Steam Deck, or an AMD host, I’d love to hear what you notice. Latency numbers, capture backend results, weird edge cases, and features you’d want next are all useful. If this belongs under a different flair, mods can move it.

u/Select_Car9532 — 1 month ago
▲ 5 r/Clevo

Looking for Clevo owners to test an unofficial Linux fan control app

Hi everyone,

I built an unofficial fan control daemon and web dashboard specifically for Clevo and Tongfang laptops running Linux. I’m looking for other Clevo owners who are willing to try it and report which models work.

It supports custom fan curves, reusable profiles, CPU and NVIDIA GPU temperature sensors, automatic recovery, configuration backups, and safety fallbacks. The web interface also shows live temperature and fan activity.

Fan control is hardware sensitive, so please read the compatibility and safety notes before installing it. Start with conservative settings and keep an eye on temperatures during the first test.

GitHub: https://github.com/vindeckyy/fan-control

If you try it, please share your exact Clevo model, Linux distribution, and whether both fans respond correctly. Compatibility reports and bug reports would help a lot.

https://preview.redd.it/8dszlljih1eh1.jpg?width=1129&format=pjpg&auto=webp&s=fcfee761f7565a381a178fcc07a8716a8e927dd3

https://preview.redd.it/8fuiqljih1eh1.jpg?width=1129&format=pjpg&auto=webp&s=e5d9e3570c097ffe2661fe4e2e9668a86a25eab9

reddit.com
u/Select_Car9532 — 1 month ago

I built a Linux fan control dashboard for Clevo and Tongfang gaming laptops

Hi all,

I use a Clevo/Tongfang laptop on Linux and wanted a better way to manage temperatures and fan noise, so I put together an unofficial fan control app.

The dashboard lets you build custom fan curves, switch between profiles, monitor CPU and NVIDIA GPU temperatures, and see how the fans respond in real time. It also includes safety fallbacks, configuration backups, and an emergency mode for temperature spikes.

I would especially appreciate feedback from anyone gaming on Linux with a Clevo or Tongfang chassis. If you test it, please check the compatibility notes and start with conservative curves.

GitHub: https://github.com/vindeckyy/fan-control

What model are you using, and how are you currently managing fan noise and temperatures on Linux?

https://preview.redd.it/t2aborsdh1eh1.jpg?width=1129&format=pjpg&auto=webp&s=1da5bf244921da7aeec3e285a89f1aa9d6c867fa

https://preview.redd.it/9e43wrsdh1eh1.jpg?width=1129&format=pjpg&auto=webp&s=621eaf093916c5389a29cbfd781acc0ca6f889cb

reddit.com
u/Select_Car9532 — 1 month ago

I made a Linux fan control app for Clevo and Tongfang laptops

Hey everyone,

I’ve been working on an unofficial fan control app for Clevo and Tongfang laptops running Linux.

It has a web dashboard for creating custom fan curves, switching profiles, monitoring temperatures, and controlling how the fans respond under load. I also added NVIDIA GPU temperature monitoring, safety fallbacks, configuration backups, and a few quality-of-life features.

I originally built it for my own laptop because I wanted something simple that gave me more control without constantly editing configuration files.

The project is still new, so feedback, testing, and hardware compatibility reports would be really helpful. Please read the compatibility and safety notes before installing it since fan control interacts directly with laptop hardware.

GitHub: https://github.com/vindeckyy/fan-control

If anyone has a Clevo or Tongfang model and tries it, I’d love to hear how it works on your machine.

https://preview.redd.it/xhbtdw08h1eh1.jpg?width=1129&format=pjpg&auto=webp&s=1a1541d5817d0244a20daf2e4752c05edffd3869

https://preview.redd.it/72a8rw08h1eh1.jpg?width=1129&format=pjpg&auto=webp&s=4dd426851d48b198ca6f7f44a7fcdb0809b4e4eb

reddit.com
u/Select_Car9532 — 1 month ago

I forked Sunshine to drop latency from "fine" to "what latency?" — here's what 124 platform-specific commits bought me

I've been running Sunshine + Moonlight for about two years. It's the best game streaming stack I've used — open source, works with any GPU, pairs with Moonlight on basically every client device that exists. I've played through most of Elden Ring on a tablet in my living room and it was fine.

But "fine" isn't the same as "I can't tell I'm streaming." There was always this baseline latency that I couldn't shake. Not unplayable — just present. You'd feel it most in games where timing matters. Hollow Knight pogo sections. Sekiro deflects. Any rhythm game. The kind of thing where you're not sure if you missed the window or the stream ate it.

I started digging into the code to see if I could fix it on my setup. What I found is that Sunshine can't fix this — not because the devs are bad (they're excellent), but because Sunshine targets twelve platforms. Windows, macOS, Linux, Intel, AMD, NVIDIA, ARM, FreeBSD. Every optimization I wanted to make would break at least three of those.

So I forked it. Called it SolarFlare. 124 commits later, it does one thing: low-latency game streaming on AMD Ryzen + Linux. Same Moonlight app, same web interface, same config files. Different numbers.


The numbers (Ryzen 5 4600H, RTX 3060, Wi-Fi 6, 1080p, Wayland)

Metric Upstream Sunshine SolarFlare
End-to-end latency (button → screen) 18–65ms 5.5–12ms
Network poll delay 80µs 15µs
Worst-case send burst 47ms <2ms
Audio sync offset ~20ms 4–8ms

The 47ms → <2ms drop on worst-case bursts was the one that made me actually say "oh" out loud at my desk. That's not a marginal improvement — that's the difference between a frame arriving when the display needs it and a frame sitting in a kernel buffer because nobody told the socket to check.

At 12ms worst case you stop thinking about the pipeline entirely and just play. That's the bar I was aiming for.


What I changed, in detail

I'm going to go through all of this because the interesting part isn't just "it's faster" — it's why it's faster, and what upstream can't ship.

Network: kernel polling instead of interrupts

This is the single biggest change. Here's how network data normally arrives: the NIC receives a packet, fires an interrupt, the kernel schedules a handler, the handler wakes up the socket, and your application's recv() call returns. That interrupt path costs about 1ms — sometimes more if the CPU is busy. Streaming 60fps means you need a new frame every 16.6ms, so burning 1ms per network operation adds up.

Linux has had SO_BUSY_POLL for years. Instead of waiting for interrupts, the CPU checks the socket directly every N microseconds. SolarFlare sets this to 50µs. The kernel just spins, looking for data, and hands it off instantly when it arrives. Network poll latency drops from 80µs → 15µs.

The cost is one CPU core running near 100%. I decided that's worth it — CPU pinning (see below) makes sure this core isn't also running your game.

There's a second network change: UDP buffer sizing. Sunshine defaults to 200KB buffers. At 4K, a single encoded frame can be 200KB. If one frame fills the buffer, the next frame blocks until the buffer drains. SolarFlare bumps this to 4MB — the encoder can queue multiple frames without ever waiting. At 1080p you won't notice this. At 4K it's the difference between smooth and hitchy.

Both are configurable. busy_poll_us (default 50, range 0–10000) and enet_4mib_buffer (default on). Set busy_poll to 0 and you're back to interrupt mode.

Rate capping that actually knows your link speed

Sunshine assumes every connection is 1 Gbps and paces the stream accordingly. If you're on 2.5GbE or a fast Wi-Fi link, that means Sunshine is intentionally under-sending — leaving bandwidth on the table and adding latency.

SolarFlare reads /sys/class/net/&lt;interface&gt;/speed to get the real link speed, then uses a configurable percentage of that (default 80%) as the rate cap. On a Wi-Fi 6 connection that reports 1200 Mbps, this means your effective cap is 960 Mbps instead of Sunshine's hardcoded 1 Gbps guess — and the pacing logic multiplies out correctly.

Config: rate_cap_pct (default 80, range 50–95).

CPU pinning + real-time scheduling

This one sounds esoteric but it's the difference between "mostly smooth" and "never stutters." When you're gaming and streaming simultaneously, your CPU has to run the game, capture the screen, encode video, process audio, and handle network I/O — all at the same time. The kernel scheduler doesn't know which threads are latency-sensitive. It'll happily put your encoder thread on the same physical core as Firefox, or schedule your capture thread to wait while a background task finishes.

SolarFlare pins encoder, capture, and audio threads to dedicated physical cores and runs them at SCHED_RR (real-time round-robin). It skips core 0 entirely — that's where most kernel interrupts and system services land — and avoids hyperthreading pairs so the pinned threads get the full physical core.

On a 6-core CPU, this reserves two cores for streaming. Your game still has four to work with. On an 8+ core chip you won't even notice the reservation. The result: the encoder never waits behind a Chrome tab. Frame timing gets dramatically more consistent.

GPU frequency governor

GPUs clock down between frames to save power. Then they clock back up when work arrives. That ramp takes a few milliseconds — and if it happens mid-stream, you get a visible hitch where a frame arrives late.

SolarFlare forces the GPU to performance governor during a stream and drops back to auto on stop. The GPU stays at max clocks the entire time. Energy cost: measurable. Latency cost of not doing it: also measurable. For a gaming session, I'll take the power bill.

This works on both AMD (via amdgpu sysfs) and NVIDIA (via nvidia-smi).

PipeWire latency hint at 8ms

Upstream Sunshine uses PipeWire's default buffer of 20–40ms for audio. That means the audio you hear is 1–2 frames behind the video you see. In a shooter, your gunshot sound lands after the muzzle flash renders.

SolarFlare requests an 8ms PipeWire buffer. One less frame of audio buffering. On normal hardware this doesn't introduce crackling or dropouts — PipeWire handles it fine. If your setup can't handle 8ms, the config knob goes from 1–40ms.

Config: pipewire_latency_ms (default 8).

NVENC presets (three modes instead of ten knobs)

NVENC has about ten parameters that interact in non-obvious ways. I replaced them with three one-click presets:

  • Latency (preset 0): zero b-frames, zero lookahead, zero-latency mode on. Competitive shooters, fighting games.
  • Balanced (preset 1): some b-frames, moderate lookahead. Most single-player games.
  • Quality (preset 2): max b-frames, full lookahead, temporal AQ on. Slow beautiful games like Cyberpunk.

Every individual knob is still available if you want to tweak. The presets just give you a sane starting point.

Per-game switching: add "encoder-preset": 0 to an entry in apps.json and SolarFlare automatically switches presets when you launch that game through Moonlight. It switches back to your default when the game ends. Set CS2 to latency mode, Cyberpunk to quality, and never touch the settings again.

Audio processing pipeline (all opt-in)

Everything here is off by default — if you don't touch these, your audio is bit-identical to upstream Sunshine. But if you want cleaner audio:

  • AGC (auto gain control): keeps explosions and whispers at similar volume so you don't ride the volume knob
  • VAD (voice activity detection) + auto-ducking: detects when someone's talking in voice chat and automatically lowers game volume so voices stay clear
  • Noise gate: mutes audio below a threshold — cuts fan hum, keyboard clatter, room noise
  • Opus encoder tuning: controls application mode (VoIP/audio/music), VBR, complexity, FEC for spotty Wi-Fi, bandwidth extension

Every parameter is exposed: attack/release/hold times, thresholds, hysteresis, attenuation. It's a full audio rack, but it ships zeroed out.

DSCP QoS tagging

One setsockopt(IP_TOS) call. Marks stream packets with a DSCP expedited forwarding tag. QoS-aware routers prioritize these packets over bulk traffic — so your game stream doesn't get stuck behind a Steam download or a Netflix buffer.

If your router doesn't support QoS, the tag is ignored. Zero overhead, zero downside. Config: dscp_qos (default on).

Headless streaming (three modes)

If you're running a dedicated streaming box with no monitor:

  1. Legacy: creates a dummy X11 display via the dummy driver. Works on older setups.
  2. KDE virtual monitor: uses KDE's built-in display tools to create a virtual output. No extra software.
  3. Gamescope headless: for Steam Deck / gaming-focused setups.
  4. Hermes-KMS kernel module: for users who want absolute minimum capture latency. A bare-bones virtual display via the kernel DRM interface — zero CPU involvement in capture, GPU writes frames directly to the encoder. Requires DKMS and kernel headers.

Most people should use option 2 or 3. Option 4 is for the "every millisecond counts" crowd.

Auto-pairing for local devices

Define your home network range in the config (192.168.1.0/24, 10.0.0.0/24) and any Moonlight client connecting from those addresses pairs automatically. No PIN entry. Set once, every new device at home connects instantly.

Adaptive bitrate

Watches network conditions in real time. When packet loss spikes or the encoder falls behind, it drops quality to keep the stream smooth. When conditions recover, it ramps back up. Better to have a slightly softer picture than a stuttery mess.

Off by default (some people want exact control over quality). Config: adaptive_bitrate_enabled.

Game library scanner

Scans Steam, Lutris, and Heroic Games Launcher for installed games. Returns name, launch path, and (for Steam) cover art URL. One click to import into your Moonlight apps list. No more manually typing launch commands.

Scoped API tokens

Upstream Sunshine requires your admin password for API access — which gives scripts full control. SolarFlare lets you create tokens with limited permissions: read-only config access, app launch/stop only, log download only. Tokens are shown once at creation (server stores a hash, not the plain text) and can be revoked.

Use case: a script that reads current bitrate and adjusts it doesn't need to be able to unpair devices or reset your display.

Ctrl+K command palette

Press Ctrl+K anywhere in the web UI and start typing. Type "bitrate" → jump to bitrate settings. Type "4k" → resolution picker. Works like VS Code's command palette or macOS Spotlight. Minor feature, but it saves a lot of clicking around once you get used to it.

System tuning services (optional)

Three one-shot systemd services that run at boot:

  • CPU governor locker: forces performance governor so the CPU never ramps down. Prevents the "wake-up lag" when a stream starts.
  • Network card tuner: sets NIC ring buffers, interrupt coalescing, and offloads for minimum latency instead of maximum throughput.
  • GPU clock locker: locks NVENC encoder clock to max frequency via nvidia-smi so the encoder never clock-gates mid-frame.

One script installs all three. Completely optional.

Build-time CPU optimization

The build script detects your Ryzen generation (Zen 1–5) and sets -march=znver1/2/3/4, -flto, -O3, -fno-plt. The binary you run was compiled for your exact CPU, not a generic x86_64 target. Not a huge difference on its own, but across 124 commits these small wins compound.

Faster startup on KDE

Some KDE setups hang for seconds during Sunshine's Wayland display enumeration. SolarFlare lets you skip that check (skip_wayland_correlation: on). Tradeoff: absolute mouse coordinates are slightly less accurate across multiple monitors. For single-monitor setups (most gaming rigs), you won't notice the difference, and startup is instant.


What I removed

Every code path that wasn't AMD Ryzen on Linux. Windows support, Intel Quicksync, ARM, FreeBSD, macOS — gone. This isn't because those platforms are bad. It's because every one of them adds conditional compilation, platform-specific workarounds, and code paths that constrain what optimizations are possible.

12 tests are skipped because they exercise hardware I don't have (NVIDIA-specific encoder tests need a physical GPU, audio tests need physical devices). 478 pass. 0 failures. Six upstream tests were deleted because they tested code paths I intentionally removed.


What this doesn't fix

  • It won't make your Wi-Fi better. If you're getting packet loss from signal issues, SolarFlare can't fix RF physics. Use Ethernet or get closer to your AP.
  • It won't help at 1080p as much as at 4K. The buffer sizing and rate cap changes matter most when frames are large. At 1080p the biggest wins are busy-poll and CPU pinning.
  • It doesn't help Intel or ARM users at all. By design. If you're on those platforms, upstream Sunshine is the right tool.
  • Balatro and Civ VI won't feel different. If your game doesn't care about 12ms vs 65ms latency, you won't notice the improvement. Rhythm games, competitive shooters, and anything with frame-perfect inputs: different story.

Install

git clone https://github.com/vindeckyy/Solar-Flare
cd Solar-Flare
./scripts/cachyos-build.sh
sudo cmake --install build
sudo setcap 'cap_sys_admin,cap_sys_nice+ep' /usr/local/bin/sunshine
systemctl --user enable --now sunshine

The build script auto-detects Arch, CachyOS, Ubuntu, Fedora, Bazzite and openSUSE — installs the right dependencies for your distro.

There's also a prebuilt binary on the releases page if you don't want to compile.


I'd love to hear numbers from anyone who tries this, especially on newer Ryzen gens (Zen 4/5), which I haven't tested. The 4600H in my laptop is Zen 2 — I'd expect even better results on a desktop Zen 4/5 chip with higher clock speeds and more L3 cache for the busy-poll thread.

Repo: https://github.com/vindeckyy/Solar-Flare 478 tests passing, 12 skipped (hardware-dependent), 0 failures.

u/Select_Car9532 — 1 month ago

I made Sunshine faster for AMD/Linux — introducing SolarFlare

MORE DETAILED INFO HERE: https://github.com/vindeckyy/Solar-Flare

---

I use Sunshine + Moonlight to stream games from my PC to my TV. Sunshine is already fantastic, but I always noticed a bit of latency, especially over Wi-Fi when the network was busy.

One thing I realized is that Sunshine has to support everything — Windows, macOS, Linux, Intel, AMD, ARM, FreeBSD. Because of that, it can't really take advantage of AMD- or Linux-specific optimizations that would break other platforms.

So I started a fork called SolarFlare. It's Sunshine optimized specifically for AMD Ryzen on Linux, now at 124 commits with a pile of platform-specific tweaks baked in.

Results

Test system: Ryzen 5 4600H, RTX 3060, Wi-Fi 6, 1080p, GNOME/Wayland

  • End-to-end latency: Sunshine 18–65ms → SolarFlare 5.5–12ms (12–53ms faster)
  • Network poll latency: Sunshine 80µs → SolarFlare 15µs
  • Worst-case send burst: Sunshine 47ms → SolarFlare under 2ms (98% smaller)
  • Audio sync offset: Sunshine ~20ms → SolarFlare 4–8ms

For me, that's the difference between "I can tell I'm streaming" and "feels like I'm sitting at the host PC."

What's changed

Kernel-level network tunables

These were previously hardcoded in Sunshine's source. Now they're configurable in sunshine.conf and auto-tuned by default:

  • rate_cap_pct (default 80): Reads your actual interface speed from /sys instead of assuming 1 Gbps. Eliminated 45ms median / 98ms p99 latency on my Wi-Fi 6 link.
  • busy_poll_us (default 50): Uses SO_BUSY_POLL to poll the NIC for 50µs instead of waiting for interrupts. Cuts receive-side wakeup from ~1ms to ~50µs.
  • pipewire_latency_ms (default 8): Passes a 8ms latency hint to PipeWire instead of the upstream default of 20–40ms. Cuts 1–2 frames of audio buffering.
  • cpu_pinning (default true): Pushes encoder/capture/audio threads onto SCHED_RR and pins them to physical cores, skipping core 0 to avoid IRQ conflicts. Removes 1–4ms scheduling hitches.
  • enet_4mib_buffer (default true): Grows UDP socket buffers from ~200KB to 4 MiB so 4K60 never stalls on sendmsg().

DSCP QoS packet tagging

Tags streaming packets with DSCP CS3. Routers that honor QoS will prioritize SolarFlare over downloads and file transfers. One setsockopt call. On by default, disable with dscp_qos = false.

GPU frequency governor

On AMD GPUs, writes "performance" to /sys/class/drm/card*/device/power_dpm_force_performance_level when streaming starts, and "auto" when it stops. Prevents the GPU from clocking down between frames. On by default, disable with gpu_governor = false.

NVENC tuning presets

Instead of tweaking 10 encoder knobs, pick from three one-click presets in the Web UI:

  • Latency-optimized: P1, 0 B-frames, zero-latency, no lookahead — competitive shooters
  • Balanced: P4, 2 B-frames, 20-frame lookahead, spatial + temporal AQ — most games
  • Quality-optimized: P7, 4 B-frames, 40-frame lookahead, full two-pass, min-QP — cinematic

New knobs exposed: B-frames, zero-latency toggle, lookahead frames (0–31), AQ strength (1–15), temporal AQ, weighted prediction, per-codec min-QP, filler data, encode surfaces. All in both the Web UI and sunshine.conf.

Per-game encoder presets

Add "encoder-preset": 0 to any app in apps.json and SolarFlare automatically switches presets per game. CS2 gets latency mode, Cyberpunk gets quality mode. Restored to default when the session ends.

Audio FX pipeline

All off by default (bit-identical to upstream):

  • AGC: automatic volume leveling with configurable target, attack, hold, release
  • VAD: speech detection to drive the ducker
  • Ducker: lowers game volume when someone's talking
  • Noise gate: cuts background hum below a threshold

Plus Opus encoder tuning: application mode (VOIP/AUDIO/LOWDELAY), VBR, complexity (0–10), in-band FEC, packet loss hint, bandwidth extension up to 24 kHz.

Headless virtual display

If headless_virtual_display = true and no monitor is detected, SolarFlare creates a virtual xrandr output and re-enumerates displays. For headless gaming servers. Opt-in.

Zen microarchitecture auto-detection

The build script reads /proc/cpuinfo and applies -march=znver1/2/3/4 automatically, plus -flto -O3 -fno-plt. The binary uses AVX2, BMI2, and FMA natively.

Multi-distro build

One script (./scripts/cachyos-build.sh) detects your distro and installs packages automatically. Tested on Arch, CachyOS, Manjaro, EndeavourOS, Ubuntu, Debian, Pop!_OS, Fedora, Nobara, openSUSE.

Everything else

  • Self-contained CI workflow (doesn't depend on LizardByte's release pipeline)
  • 23 upstream commits cherry-picked since the June 2026 fork base
  • 9 regression guard tests that fail the build if a cherry-pick gets accidentally reverted
  • Web UI rebrand: SolarFlare logo, fork-named themes, footer pointing at the repo
  • sunshine --version prints fork name, repo URL, and commit hash
  • 22 upstream workflow files pinned to stop them firing on the fork

The catch

AMD Ryzen + Linux only. If you're on Windows, Intel, or ARM — use upstream Sunshine. SolarFlare intentionally drops cross-platform support to enable these optimizations.

Install

git clone https://github.com/vindeckyy/Solar-Flare.git
cd Solar-Flare
./scripts/cachyos-build.sh
sudo cmake --install build
sudo setcap 'cap_dac_override,cap_sys_admin,cap_sys_nice+ep' /usr/local/bin/sunshine
systemctl --user enable --now sunshine.service

Pair with Moonlight at https://localhost:47990.

Status

124 commits, 406/412 tests passing, 42 fork-specific tests, actively maintained.

GitHub: https://github.com/vindeckyy/Solar-Flare

If you try it, I'd love to hear your numbers — especially on different Ryzen gens or with Wi-Fi 7

u/Select_Car9532 — 2 months ago