Ben C's Blog

Steam Remote Play Headless

Sat, 17 Jan 2026 00:00:00 GMT

For a while, I've wanted a setup where I can simply SSH into my desktop, start Steam, and use remote play to play my games.

Gamescope offers a backend called headless that allows me to do this, after some messing around I got it working mostly.

There's other software like Sunshine that seem cool and have NixOS modules. I chose to avoid these because of the extra setup they need, and my use-case is a lot simpler than what they're made for.

Steam/Gamescope Setup

First some manual setup for Steam, I had to enable Remote Play and pair my laptop to my desktop for the first time. when you first try to connect to a device to remote play from it, you need to enter a PIN on the host.

Luckily I have a monitor plugged into my desktop so I just turned that on, opened Steam in a graphical session, and got everything set up. Hopefully I only have to do this once (but also Steam loves to clear my preferences so we'll see).

My NixOS setup for steam and gamescope is this:

{
  programs.steam = {
    enable = true;
    remotePlay.openFirewall = true;
    extest.enable = false; # I'll explain this in a sec.
  };

  programs.gamescope = {
    enable = true;
    capSysNice = false; # I'll explain this too.
  };
}

Extest

We disable extest since it's not really needed, and it will panic when you try to send any input to a game Steam launches. false is the default so you can omit the line, but figured I should mention it.

capSysNice

This is an already discussed issue. The way I'm launching gamescope is causing issues with bubblewrap passing the sysnice capability to Steam. I just disable that and renice it later.

I'm like 80% sure this is a skill issue on my part to be honest. Most stuff says this has been fixed, at least in the NixOS module for Steam.

Running Steam

With Steam set up and those options enabled, we can run gamescope. My laptop uses a 2256x1504 resolution so I'm setting that here. I set both gamescope's resolution (-W/-H) and Steams (-w/-h).

gamescope -W 2256 -H 1504 -w 2256 -h 1504 --backend headless --steam -- steam -tenfoot -pipewire-dmabuf

We launch gamescope with our preferred resolution, with a headless backend and Steam integration enabled. Then we launch Steam in big picture mode.

I'll usually start this in a GNU screen session so it doesn't stop Steam if my SSH session drops.

screen -S steam # Before running gamescope

Re-nicing

Finally just renice all gamescope processes because it can start to degrade in performance after a while allegedly.

sudo renice -n -20 -p $(pgrep -d " " "gamescope")

Not the best solution but works fine. You could also repeat this for Steam and the game you're running once it launches.

Final Results

On a wired connection all the games I've tested are responsive and work very well besides some minor issues that are more a Linux/NixOS thing™ than specific to this. Here's a screenshot from Portal 2 with the overlay enabled.

Consistently I get <1ms input latency and ~20ms display latency in-game, which for me is perfectly acceptable. I'm able to have all the settings on high now without my laptop becoming a nice and toasty 100°C.

The nice thing is how I can choose to start this whenever I want remotely; I don't need a Steam session always open on a display on my desktop. I do wish Steam would let me add non-steam games in the big-picture UI because I still have to do that manually.

Conclusion

I'm sure Sunshine is way better in both performance and versatility but this works well enough for me and requires far less setup that I can deal with it. Security-wise I didn't want to introduce an entirely new service just to stream games, especially since it has an entire auth system to set up.

Connecting via SSH is already easy since I use keys, and Steam handles everything for the actual remote play authentication for me already, so I see it as a much simpler setup.

Of course Sunshine does a lot more than Steam so it's not really a fair comparison. I might end up trying it anyways to see how well it works.

First blog post in 2 years, maybe I'll make another one this decade!

Custom Screen Capture Flow

Thu, 25 Jul 2024 00:00:00 GMT

I've recently been going down the path of madness known as customizing my desktop and I figured I'd share some neat scripts and setups I've done along the way.

Today I'll go into some scripts I've been working on to capture screen shots and recordings. They allow selecting regions of the screen and specific windows, and I also made it so you can edit them afterwards.

Background

My entire system and home folder is managed by NixOS, so I have a configuration repository where all my scripts and configs can be found, I'll reference them throughout this post and provide links to the current version of each so you can see if I've updated them since this post.

Currently I use Hyprland as my window manager, and have been duct-taping components together to make my own little Desktop Environment around it.

I also like to use NuShell as my shell, and these scripts will be written in it. If you haven't checked out NuShell yet, I highly recommend it!

Screenshots

First is the script to take screenshots. This is a relatively simple script as it simply builds on top of grimblast with some nice QoL features.

To install grimblast, all I have to do is add it to my environment.systemPackages:

{
  environment.systemPackages = with pkgs; [
    # ...
    grimblast
    libnotify # For notifications
    xdg-utils # For opening files
    # ...
  ];
}

Grimblast will automatically save screenshots to XDG_SCREENSHOTS_DIR, I manually set this in my home manager config with:

{
  xdg.userDirs.extraConfig.XDG_SCREENSHOTS_DIR = "${config.home.homeDirectory}/Pictures/Screenshots";
}

Grimblast will name the screenshots with the current date and time, which works for me.

Now along to actually using grimblast, I'll create a new script and put in in my config somewhere, we'll call it screenshot.nu. I usually like to place any non-nix files in a folder called res at the root of my config, we'll get to actually calling this script once we're done writing it.

To start out we need to call grimblast, I like to use copysave as the action as I like having it immediately in my clipboard, and having it saved for later. I'll also add --freeze which simply freezes the screen while I select the region to capture.

let file_path = grimblast --freeze copysave

grimblast will then return the path to the saved screenshot, which we save in file_path. If the user were to cancel the selection (press escape), file_path would be empty, so we want to make sure to check for that so we're not trying to open a non-existent file.

if $file_path == "" {
    exit 1
}

Now the main part, we'll send a notification that the screenshot was saved, and have options for it.

I want four actions for the screenshot:

Open
Open Folder
Edit
Delete

Also since grimblast saves the screenshot as a png, I can pass it as the icon of the notification.

let choice = notify-send --app-name=screengrab -i $file_path -t 7500 --action=open=Open --action=folder="Show In Folder" --action=edit=Edit --action=delete=Delete "Screenshot taken" $"Screenshot saved to ($file_path) and copied to clipboard"

A long command here, notify-send allows us to send a notification to the currently running notification daemon. In my case I'm using swaync.

--app-name is the name of the application that sent the notification, I say screengrab here so swaync will show an icon in addition to the image, also so I can play a camera shutter sound when the notification is sent.
-i is the icon to display in the notification, in this case the screenshot we just took.
-t is the time in milliseconds to show the notification
--action is actions to display in the notification, name=Text
First position argument is the notification title, and second is the body.

With that we get a neat notification when we screenshot.

Now we need to handle each action, the chosen action is returned by notify-send, so we can match on that.

"Open" and "Open Folder" are pretty simple, just pass $file_path and $file_path | path dirname to xdg-open
"Edit" I'll simply pass the file path to my editor, I chose swappy because of it's simplicity and ease of use.
"Delete" I'll just remove the file.

match $choice {
    "open" => {
        xdg-open $file_path
    }
    "folder" => {
        xdg-open ($file_path | path dirname)
    }
    "edit" => {
        swappy -f $file_path
    }
    "delete" => {
        rm $file_path
    }
}

And that's it! I now have a fairly robust screenshot script.

Screenshot Invocation

Now in terms of actually calling it I'll be binding it to Win + Shift + S in Hyprland, as well as PrintScreen.

In home manager I simply have to add these strings to my Hyprland binds

{
  wayland.windowManager.hyprland.settings.bind = [
      # ...
      ",Print,exec,nu ${../res/screenshot.nu}"
      "SUPER SHIFT,S,exec,nu ${../res/screenshot.nu}"
      # ...
  ];
}

Now by switching to my new config (and making sure to stage screenshot.nu of course), I can take screenshots with a keybind!

Screen Recordings

This will be a bit more involved mainly because something like grimblast doesn't exist for screen recordings. Looking at existing solutions I couldn't find any that I really liked, mostly because they involved some additional UI. To be clear this script will be for simple, short recordings, long-term stuff I'll still prefer to use something like OBS.

For the actual screen recording I'll be using wf-recorder.

{
  environment.systemPackages = with pkgs; [
    # ...
    wf-recorder
    libnotify # For notifications
    xdg-utils # For opening files
    slurp # Will explain this later
    # ...
  ];
}

First and foremost location, I chose to use ~/Videos/Captures for my recordings. I didn't set an environment variable for this, it'll be hardcoded in the script.

let date_format = "%Y-%m-%d_%H-%M-%S"

let captures_folder = $"($env.HOME)/Videos/Captures"

if not ($captures_folder | path exists) {
    mkdir $captures_folder
}

let out_name = date now | format date $"($captures_folder)/($date_format).mp4"

This will handle determining the folder and name for the recordings, and creating the folder if it doesn't exist.

Next up I want to have a similar selection process to the screenshot script, to do this I'll use slurp to select areas of the screen, which is what grimblast uses under the hood.

In addition, grimblast does some communication with Hyprland to get window information such as position and size, this lets you select a window to take a screenshot of. I'll be getting that info manually from Hyprland using NuShell instead:

let workspaces = hyprctl monitors -j | from json | get activeWorkspace.id
let windows = hyprctl clients -j | from json | where workspace.id in $workspaces
let geom = $windows | each { |w| $"($w.at.0),($w.at.1) ($w.size.0)x($w.size.1)" } | str join "\n"

This gets all the geometry in a format slurp will be able to parse and use.

let stat = do { echo $geom | slurp -d } | complete

if $stat.exit_code == 1 {
    echo "No selection made"
    exit
}

I do complete here to get the exit code of the slurp command, if it's 1 then the user cancelled the selection and similar to the screenshot script I'll exit.

Now it's time to actually record, the stdout of slurp contains the geometry that we want to capture, so we'll pass that to wf-recorder with the -g flag:

wf-recorder -g ($stat.stdout) -F fps=30 -f $out_name

Pretty simple command, -g is the geometry to record, -F is the format options, and -f is the output file.

Now we'll run into an issue if we run this script and start recording, there's no way to stop it! I'll cover how we're going to get around that when it comes to setting up keybinds.

Assuming wf-recorder stops, we'll send a notification to the user that the recording is done:

let action = notify-send --app-name=simplescreenrecorder --icon=simplescreenrecorder -t 7500 --action=open=Open --action=folder="Show In Folder" --action=delete=Delete "Recording finished" $"File saved to ($out_name)"

Most arguments are the same here as the screenshot script, the only difference is the icon and app name. The actions are also basically the same, so I'll leave out the explanation and just show the handler:

match $action {
    "open" => {
        xdg-open $out_name
    }
    "folder" => {
        xdg-open $captures_folder
    }
    "delete" => {
        rm $out_name
    }
}

Start/Stop Recording

Now to actually call the script, I'll bind it to Win + Shift + R in Hyprland.

However, we're going to do something special with the exec line here. Instead of simply calling the script we're going to check if wf-recorder is already running, if this is the case we can send SIGINT to it to make it stop recording, meaning our script will continue and show the notification.

{
  wayland.windowManager.hyprland.settings.bindr = [
      # ...
      "SUPER SHIFT,R,exec,pkill wf-recorder --signal SIGINT || nu ${../res/screenrec.nu}"
      # ...
  ];
}

pkill here will exit with code 1 if it doesn't find any processes to kill, so the || will run our script if pkill fails.

Note that I did this on bindr, this means the keybind will only happen once the R key is released rather than pressed. This is to prevent a weird issue I ran into where the recording would stop immediately after starting.

And that's it! We can now screen record with ease. It won't record audio (might do an additional keybind in the future) and it also doesn't copy the recording to the clipboard, but it works pretty well for short videos.

Full Scripts

Screenshot Script

#!/usr/bin/env nu

let file_path = grimblast --freeze copysave area

if $file_path == "" {
    exit 1;
}

let choice = notify-send --app-name=screengrab -i $file_path -t 7500 --action=open=Open --action=folder="Show In Folder" --action=edit=Edit --action=delete=Delete "Screenshot taken" $"Screenshot saved to ($file_path) and copied to clipboard"

match $choice {
    "open" => {
        xdg-open $file_path
    }
    "folder" => {
        xdg-open ($file_path | path dirname)
    }
    "edit" => {
        swappy -f $file_path
    }
    "delete" => {
        rm $file_path
    }
}

Most recent version on GitHub

Recording Script

#!/usr/bin/env nu

let date_format = "%Y-%m-%d_%H-%M-%S"

let captures_folder = $"($env.HOME)/Videos/Captures"

if not ($captures_folder | path exists) {
    mkdir $captures_folder
}

let out_name = date now | format date $"($captures_folder)/($date_format).mp4"

let workspaces = hyprctl monitors -j | from json | get activeWorkspace.id
let windows = hyprctl clients -j | from json | where workspace.id in $workspaces
let geom = $windows | each { |w| $"($w.at.0),($w.at.1) ($w.size.0)x($w.size.1)" } | str join "\n"

let stat = do { echo $geom | slurp -d } | complete

if $stat.exit_code == 1 {
    echo "No selection made"
    exit
}

wf-recorder -g ($stat.stdout) -F fps=30 -f $out_name

let action = notify-send --app-name=simplescreenrecorder --icon=simplescreenrecorder -t 7500 --action=open=Open --action=folder="Show In Folder" --action=delete=Delete "Recording finished" $"File saved to ($out_name)"

match $action {
    "open" => {
        xdg-open $out_name
    }
    "folder" => {
        xdg-open $captures_folder
    }
    "delete" => {
        rm $out_name
    }
}

Most recent version on GitHub

Welcome to my blog!

Sun, 15 Oct 2023 00:00:00 GMT

import CowSay from "@components/blog/CowSay.astro";

Hey there

I decided to make this blog as a way to track my progress in learning new things. I hope you enjoy your stay!

This first post is going into a bit of detail about how I made this blog.

Making The Basic Blog

Astro has a wonderful feature called the content framework, an extremely powerful way to easily create many pages with simple markdown and some frontmatter.

First thing you have to to do is create a folder called content in the src directory. I already had some content setup because of the projects parts of this site.

Inside the content folder you place a config.ts which will contain the schemas for your content's frontmatter. I'll just focus on my blog posts for now.

const blogPostsCollection = defineCollection({
  schema: z.object({
    title: z.string(),
    date: z.date(),
    summary: z.string(),
    cowsay: z.string()
  })
});

This contains the metadata each blog post will need to have in order for my site to render it.

Then, we export an object named collections which Astro will pick up and generate TS bindings for.

export const collections = {
  posts: blogPostsCollection
};

Now we can get to writing some content! Make a folder with the same name as the key of the collection you want to write for. In this case, posts.

Then create a markdown file and start writing! Here's a little excerpt of what this page looks like:

---
title: Welcome to my blog!
date: 2023-10-15
summary: How I built my blog.
cowsay: Hello World!
---

## Hey there

The frontmatter is the part between the --- and ---. This is where you put metadata for the post. The cowsay field is a special one that I made up. It changes what the cow says in the header of the page. I'll get to that later.

Now that we have some content, we can start writing some code to render it!

I start off by making a blog folder in the src/pages directory. This is where all my blog related pages will go. I then make a index.astro file which will be a directory of all posts on the site.

---
import Layout from "@layouts/Layout.astro";
import { getCollection } from "astro:content";

const blogEntries = await getCollection("posts");
---

<Layout title="The Cowsay - Ben C's Blog">
  <h1>The Cowsay - Ben C's Blog</h1>
  <p>Here you'll find my blog posts, most recent first</p>
  {
    blogEntries.map((p, i) => (
      <>
        {i === 0 && <hr />}
        <hgroup>
          <h2>
            <a href={`/blog/posts/${p.id}`}>{p.data.title}</a>
          </h2>
          <h3>
            {p.data.date.toLocaleDateString("en-us", {
              weekday: "long",
              year: "numeric",
              month: "short",
              day: "numeric"
            })}
          </h3>
        </hgroup>
        <p>
          {p.data.summary}&nbsp;&nbsp;<a href={`/blog/posts/${p.id}`}>Read More</a>
        </p>
        <hr />
      </>
    ))
  }
</Layout>

Great! I'll probably fiddle with it in the future but it's a good start. Now we need to make a page for each post. To make my URLs look nice I'm going to create a subfolder within blog called posts and then place a [...id].astro in there. This will allow me to use getStaticPaths() to define the paths for each post.

---
import Layout from "@layouts/Layout.astro";
import { CollectionEntry, getCollection } from "astro:content";
export const getStaticPaths = async () => {
  const posts = await getCollection("posts");
  return posts.map((entry) => ({
    params: { slug: entry.id },
    props: { entry }
  }));
};

const { entry } = Astro.props as { entry: CollectionEntry<"posts"> };
const { Content } = await entry.render();
---

<Layout title={entry.data.title} description={entry.data.summary}>
  <h1>{entry.data.title}</h1>
  <Content />
</Layout>

<style is:global>
  main img {
    border: solid 1px var(--text) !important;
    border-radius: 5px;
  }
</style>

Amazing! I'll spare you the image this time since... you're... look at it. But now we have a blog post page! Now anytime I want to make a new post I just have to make a new markdown file and it'll be rendered on the site.

An Outline

Now that we have a basic blog, I want to add a few more features to it. First I want to add the ability to see all headers in a post. This should be pretty easy to do. Astro automatically parses all the headers for us and lets us access them in the entry object.

First we need to grab the headings from when we rendered the page:

const { Content, headings } = await entry.render();

Then we need to map those to HTML

<div class="toc">
  <!-- Extra div so we can make it sticky -->
  <div>
    <span>On This Page</span>
    <ul>
      {
        headings.map((h) => (
          <li>
            <a href={`#${h.id}`}>{h.text}</a>
          </li>
        ))
      }
    </ul>
  </div>
</div>

Finally some simple styles and layout

<style>
  /** Wrapper is going around everything to make the
        table of contents appear on the right of the page **/
  div.wrapper {
    display: flex;
    flex-direction: row;
    gap: 4rem;
  }

  div.toc {
    width: 100%;
  }

  div.toc div {
    top: 5rem;
    margin-top: 1rem;
    position: sticky;
  }

  div.toc ul li {
    list-style-type: none;
  }
</style>

Finally, I want to make sure on smaller screen sizes the table of contents appears at the top rather than the side so it doesn't take up too much space.

div.wrapper {
  display: flex;
  flex-direction: column-reverse;
  gap: 1rem;
}

@media (min-width: 1200px) {
  div.wrapper {
    flex-direction: row;
    gap: 4rem;
  }
}

The Cowsay

Now for the fun part. I want to make a little cow that says something in the header of each post. I'm going to use the cowsay field in the frontmatter to do this. I'll also provide a CowSay component that will render the cow and the text. This way I can use it MDX for admonitions.

First I need to make a component that will render the cow. I'm going to use the cowsay package to do this.

---
import * as cowsay from "cowsay";

type Props = {
  color?: "warn" | "info";
} & cowsay.IOptions;

const { color, ...cowOptions } = Astro.props;

const cowText = cowsay.say(cowOptions);
---

<pre class={color}>
{cowText}
</pre>

<style>
  pre {
    padding: 1rem;
  }

  pre.warn {
    color: yellow;
    background-color: rgb(25, 25, 0);
  }

  pre.info {
    color: cyan;
    background-color: rgb(0, 25, 25);
  }
</style>

Now I can link it up in my blog post page!

<CowSay text={entry.data.cowsay} />

Et voila! A cow that says something in the header of each post! I'll probably make it a bit more fancy in the future but for now it's good enough.

I can also use it for admonitions in MDX!

<CowSay color="warn" e="><" text="Warning!" />
<CowSay color="info" e="^^" T="U" text="Info!" />

Conclusion

I'm really happy with how this blog turned out. I'm going to keep working on it and adding new features as I go. I'm also going to try and write more posts in the future. I hope you enjoyed this one!