Studio Mode

Studio Mode hands your machine to the app you are actually working in. The focused app gets priority, protected memory and the largest share of CPU and I/O, while every other open application is held back — throttled to the bottom of the queue. Switch it off and everything comes back exactly as it was.

It is useful whenever one thing matters more than everything else: a game, a render, a compile, a DAW, or Genesi Code with a dev server running.

genesi-studio on                       # the focused window gets the machine
genesi-studio on blender               # …or name the app
genesi-studio on genesi-code firefox   # …or several at once
genesi-studio off                      # thaw everything, restore every tweak
genesi-studio info                     # what it is doing right now
genesi-studio list                     # what is open, and what is focused

Held back, not closed

Closing background apps would be the crude way to free a machine, and it loses unsaved work — "restore" could only ever relaunch the app, never reopen its documents. So Studio Mode never closes anything.

By default it throttles the background apps: each is reniced to the lowest priority with its I/O in the idle class, so it keeps running but sits at the very bottom of the scheduler while the focused app takes the machine. The app keeps its memory and its state and returns to full speed the moment you switch Studio Mode off.

A literal zero-CPU freeze (the kernel's cgroup v2 freezer, SIGSTOP as a fallback) is still available for X11 users who want it and don't mind those dialogs:

genesi-studio set suspend_method=freeze   # default is "throttle"

Apps you launch after switching Studio Mode on are never touched. The set is a snapshot taken at activation — silently holding back a window the moment it appeared would be indistinguishable from a hang.

What is never touched

Suspending the compositor would take the desktop down with it, including the widget you would use to turn Studio Mode off. So it is restricted twice over:

• only processes that own a window are candidates, never background daemons;
• and a protected set is excluded even when it has a window: compositors and shells (plasmashell, kwin, Hyprland, gnome-shell, xfwm4, cinnamon, budgie-panel, lxqt-panel, cosmic-comp, niri, quickshell), session infrastructure (systemd, D-Bus, PipeWire, portals, polkit, keyring), the display manager, and Genesi's own daemons.

Add your own exceptions — a music player, a chat client, a running build:

genesi-studio set never_freeze=spotify,discord,element

What it actually changes

Per focused app:

Machine-wide, while a session is running:

The memory levers matter more than they look. A game or editor that gets paged out stutters for seconds when it next touches that memory, and no amount of CPU priority recovers it.

Deliberate restraint

Three things Studio Mode does not do, each for a reason found the hard way:

• nice stops at -5. Going harder let the focused app win the CPU over the compositor, so its own window repainted less often and it felt laggier despite having more CPU. It also fought ananicy-cpp, which manages nice per-app across Genesi.
• I/O priority is best-effort, never realtime. The realtime I/O class can starve journald and systemd and wedge the desktop — precisely the outcome Studio Mode exists to prevent.
• Core pinning only happens on hybrid CPUs. On a uniform CPU (any Ryzen, older Intel) or in a VM, "fastest cores" means either every core or measurement noise, and pinning to a subset only takes cores away from the app.

Seeing which app has the machine

The focused window is outlined in Genesi green.

On Hyprland and Niri the compositor is asked to recolour the border directly. On X11 desktops (KDE, Xfce, Cinnamon, Budgie, LXDE, MATE) no such API exists — a window's decoration belongs to its decoration plugin, and nothing outside it can tint one window differently — so the outline is drawn by a small click-through helper that follows the window as it moves.

The panel widget is the indicator everywhere else.

Desktop coverage

Studio Mode needs to know which windows are open and which one is focused, and every compositor answers that differently:

GNOME on Wayland exposes no window list to third parties at all, which is why the bundled GNOME Shell extension matters: running inside the shell, it can read the real focused window. Enable Genesi Studio Mode in the Extensions app.

COSMIC currently falls back to listing applications rather than windows. Full focus-following there needs a Wayland toplevel client, and neither ext-foreign-toplevel-list-v1 nor cosmic-toplevel-info-v1 exposes a process ID — so the work is bridging an app ID back to a PID, not speaking the protocol.

The widget

The Studio Mode widget ships on the default Genesi panel. If you are upgrading an existing install and it is not there, add Genesi Studio Mode from the panel's widget list.

• KDE — a Plasma 6 widget: the focused app's own icon and name headline the popup, with the paused apps listed below.
• GNOME — a Shell extension.
• Everything else, including COSMIC — a system-tray applet (genesi-studio-tray), autostarted on every desktop except KDE and GNOME.

All three read the same state file and drive the same CLI, so they cannot disagree about what Studio Mode is doing.

To focus more than one app, tick several in the picker and confirm.

Nothing gets stuck

A held-back app outlives the daemon — a renice, and cgroup freeze state, live in the kernel, not in Studio Mode. So the undo record is written before anything is touched, a starting daemon restores a stale session before doing anything else, the systemd unit restores on stop, and the privileged helper restores its baselines on shutdown. Studio Mode also switches itself off when the focused app exits.

How it is put together

Three processes, one control path:

The split exists for security. Freezing your own processes needs no privilege, so the session daemon never runs as root. The levers that do need root live in a helper whose entire control surface is a single Unix socket, where every request is authenticated with SO_PEERCRED — a credential supplied by the kernel that the caller cannot forge — and a non-root caller may only ever name process IDs it already owns.

Troubleshooting

The picker lists background processes instead of my windows. The session daemon could not reach the display server and fell back to a /proc scan. Check which backend is in use:

genesi-studio list

A healthy X11 session reports no fallback notice. If it does, restart the daemon with your apps already open:

systemctl --user restart genesi-studiod

An app is missing from the picker. Studio Mode can only act on windows it can resolve to a process. A window that advertises no process ID is matched by its window class instead, but one that matches nothing at all is skipped — there would be no process to prioritise or freeze.

Nothing appears to happen when I switch it on. By design — the background apps keep running, just slowly, and a notification tells you how many were held back. Confirm what it is doing with:

genesi-studio info

In freeze mode, suspended processes show state T (stopped) in top and ps.