DEV Community: Mathis

Recording screen on Linux: the state of things in 2026

Mathis — Sun, 31 May 2026 07:13:29 +0000

Recording screen on Linux: the state of things in 2026

If you have ever tried to record your screen on Linux, you already know the landscape is fragmented. Some tools only work on X11, others work on Wayland but lack basic features, and a few try to do everything and end up with a setup process that takes longer than the recording itself.
I have been building a screen recorder for Linux for the past year, and I have tested every option I could find along the way. This is where things stand right now.

The built-in option: GNOME screen recorder

If you are on Ubuntu or Fedora with GNOME, you already have a screen recorder built in. Press Ctrl+Alt+Shift+R and it starts recording, press it again to stop.
The problem is that it is extremely limited. There are no audio controls, no webcam overlay, no zoom, and no cursor effects. The output is a WebM file that you will probably need to convert before sharing anywhere. It works for quick bug reports but it is not a tool for making content that people actually want to watch.

OBS Studio

OBS is the one everyone knows. It is free, open source, and works on Linux with full support for live streaming to Twitch and YouTube, multi-source scenes, capture cards, browser overlays, and advanced audio routing. If you need any of those things, OBS is the right choice and nothing else comes close.
But OBS was built for streaming, and when you use it for tutorial recording you end up doing a lot of setup that has nothing to do with the content you are trying to make. You configure scenes, add sources, set up audio devices, and tweak output settings before you can even hit record. If you want smooth zoom effects you need plugins or scripts, and if you want cursor emphasis you need more plugins or post-production editing.
OBS is the best free tool for streaming and complex productions, but it is not the best tool for recording a quick tutorial on Linux.

SimpleScreenRecorder

SimpleScreenRecorder does what it says on the tin. It records your screen on X11 with a simple interface and minimal resource usage, and it is reliable and lightweight for what it does.
The catch is that it only works on X11, which means no Wayland support at all. There are also no zoom effects, no cursor overlay, and no editing capabilities. If you are on a modern Linux desktop running Wayland, which is now the default on both Ubuntu and Fedora, SimpleScreenRecorder simply will not work.

Kazam

Kazam is another simple recorder built for GNOME with a clean interface and webcam overlay support that works for quick clips.
The problem is that Kazam has not seen meaningful development in years. Wayland support is partial at best, there are no zoom effects or cursor styling, and codec options are limited. It works for basic recording but it has not kept up with what Linux creators actually need in 2026.

VokoscreenNG

VokoscreenNG has more features than Kazam with scheduled recordings, multiple capture modes, and cross-platform support for both Linux and Windows, all open source.
The tradeoff is that the UI feels dated, there are no zoom or cursor effects, and the community around it is small. It is a step up from Kazam if you need scheduling but it is still a basic recorder that does not go beyond raw capture.

Kooha

Kooha is worth mentioning because it is one of the few recorders that was built for Wayland from the start, using PipeWire for screen capture which is the correct modern approach on Linux.
The tradeoff is that Kooha is minimal to a fault. There are no zoom effects, no cursor styling, and no editing tools. It records your screen and saves a file, and if you just need a clean Wayland recording with no fuss then Kooha works well. But if you need anything beyond raw capture you will need another tool to make the output look presentable.

Screenix

I built Screenix because none of these tools did what I needed. I wanted to record a tutorial on Linux and have it look polished without spending time in an editor afterward.
Screenix records your screen with automatic smooth zooms that follow your cursor. You click somewhere and it zooms in, you move to another area and it follows, and when you stop recording the zoom effects are already baked into the video with no keyframes or plugins or post-production required.
It also handles cursor styling with 15 themes, click emphasis, camera overlay with transitions, clip cutting, speed adjustments, blur and highlight zones, and a screenshot editor that lets you capture, beautify, and export screenshots in one click.
It works on both X11 and Wayland through PipeWire, with support for Ubuntu 22.04+, Fedora 40+, Arch, Manjaro, CachyOS, and Linux Mint. You install it, hit record, and the output is ready to share.
The downside is that Screenix is paid software. There is a 7-day free trial with full exports and no credit card required, but after that it requires a license. It also does not support live streaming, and it is Linux only with no Windows or macOS build.

Where things stand

The Linux screen recording landscape in 2026 breaks down pretty clearly. OBS Studio is still the answer for streaming and complex productions, and nothing else comes close for that use case. SimpleScreenRecorder is lightweight and reliable if you are still on X11. Kooha and the GNOME built-in recorder work for basic Wayland capture but they are limited to raw recording with no polish. And Screenix is the only option on Linux that handles zoom, cursor effects, and editing in one workflow for people making tutorials and demos.
The gap that still exists is between free tools that do raw capture well and paid tools that handle the post-production workflow. Most Linux creators end up recording with one tool, editing with another, and spending time on zoom effects and cursor highlighting that should not require manual keyframes in 2026.
If you want to try Screenix, the free trial is at screenix.studio. No credit card required, full exports for 7 days.

I'm 19 and I Built a Screen Studio Alternative for Linux with Rust and wgpu, Here's What I Learned

Mathis — Wed, 18 Mar 2026 12:37:16 +0000

I'm 19 and I Built a Screen Studio Alternative for Linux with Rust and wgpu, Here's What I Learned

Try Screenix here!

I got tired of waiting for someone else to build it.

If you're on macOS and record videos for your dev blog or your product, you've probably used Screen Studio. It's polished, it exports beautifully, the zoom animations feel intentional. On Linux you get OBS (which is powerful but built for streaming, not short product demos) or some GNOME recorder that exports a flat .webm. That's it.

I'm Mathis. I'm 19, I do indie dev full-time, and I spent the last few months building Screenix, a screen recorder and video editor for Linux with automatic zoom, cursor tracking, and clean export. I built it in Rust with wgpu for rendering. I have 2 paying customers so far and a long list of things that were harder than I expected.

This post is about the hard parts.

Why Rust and wgpu

Not because I wanted to suffer. Rust felt like the right call for a native Linux app where I needed direct control over rendering, memory, and system APIs. I didn't want to wrap Electron around everything or fight with GTK's rendering pipeline when I needed frame-accurate video output.

wgpu gave me a portable GPU abstraction that works on Vulkan on Linux and could potentially work on other backends later. The learning curve was steep, but once the mental model clicked, the control it gave me over the rendering loop was worth it.

The Hardest Part: Wayland Cursor Tracking

This is where I spent probably the most unexpected amount of time.

On X11, getting the cursor position is straightforward. On Wayland, the compositor controls everything and doesn't just let you query a global cursor position whenever you want. This is by design for security, but it makes building a screen recorder genuinely annoying.

My first approach was a GNOME Shell extension. I wrote a small extension that exposed the cursor position over D-Bus, and Screenix would query it from the extension. It worked, but it meant requiring users to install and enable a separate extension before they could even start recording. Not ideal for a product that's supposed to feel polished.

I eventually moved the position tracking to use the SPA (Simple Plugin API) metadata, which is part of the PipeWire ecosystem. PipeWire is the audio and video routing layer that modern Linux desktops use, and SPA metadata lets you attach arbitrary data to streams, including pointer position. This was cleaner because if you're capturing the screen through PipeWire anyway (which you are on Wayland), the cursor position can travel with the stream without needing a separate channel.

But there's a catch: I still use the GNOME Shell extension for the cursor shape.

The cursor shape (whether the cursor looks like an arrow, a hand, a text cursor, etc.) is separate from the position. PipeWire doesn't expose this. The Wayland protocol has a cursor-shape protocol, but getting the shape of the cursor as seen by another application, not your own, requires compositor cooperation. The extension is the only reliable way I found to get this on GNOME Wayland. So there's still a dependency, just a reduced one.

If you know a better way, I genuinely want to hear it.

What Went Wrong with the Editor Engine

The editor is where the product actually differentiates itself from "just a recorder." You record, then you get a timeline where you can add zoom effects, adjust the cursor smoothing, and export.

The zoom system was conceptually simple: track the cursor, add smooth keyframes around fast cursor movements, scale the viewport. In practice I had to think carefully about when to trigger a zoom (not every mouse movement, that would be seizure-inducing), how to smooth the easing so it doesn't feel mechanical, and how to handle recordings where the cursor barely moves versus recordings where it's flying across a 4K display.

The manual zoom layer I built on top of the automatic one took longer than expected because I needed a good interaction model. You scrub the timeline, you set a zoom region, you adjust it. Getting this to feel responsive in the editor while not killing export performance required separating the preview rendering from the export pipeline.

Export speed is still something I'm actively working on. The bottleneck right now is in how I'm handling frame composition before encoding. I haven't fully optimized the wgpu pipeline for batch frame output yet.

What I Underestimated

A few things I thought would be easy that weren't:

Fedora support. PipeWire versions and GNOME versions vary more than I expected between Ubuntu and Fedora. Things that worked on one didn't work on the other. I ended up having to test both and handle some version-specific paths explicitly.

The extension installation UX. Even with the reduced dependency, asking users to install a GNOME extension is friction. A lot of people don't know how to do it, or they're on a locked-down system, or they're not on GNOME at all. I need a better fallback story for non-GNOME Wayland compositors. KDE Plasma handles things differently.

Being the only person working on this. Not a technical problem, but it's real. Every bug I hit, I hit alone. There's no one to rubber duck with at 2am when the wgpu render pass is producing artifacts I don't understand. I got good at reading spec documents and graphics debugging tools.

What Actually Worked

The rendering approach with wgpu turned out to be the right call. Once I had the pipeline working, adding effects like zoom, cursor highlight, and background rendering was additive rather than a constant fight with the existing architecture.

The PipeWire integration is solid. Using the native Linux AV stack instead of trying to capture frames through X11 hacks means the capture quality is good and the approach is forward-compatible as more distros move fully to Wayland.

Building in public on X helped me stay accountable. Posting daily recordings made with Screenix, of Screenix being built, was a neat loop that also forced me to actually use the product every day.

Where It's Going

Current focus is export speed and picture-in-picture. After that I want to improve the cursor smoothing algorithm and add support for non-GNOME compositors.

If you're building something on Linux and struggling with Wayland capture, PipeWire integration, or wgpu rendering, feel free to reach out. And if you're on Linux and need a screen recorder that actually looks good, that's what Screenix is for.

Still building.