xXJSONDeruloXx/decky-lsfg-vk: a Decky plugin for lsfg-vk frame generation

What the Decky plugin adds on top of the lsfg-vk layer

Lossless Scaling frame generation is a Windows feature, and lsfg-vk is a Vulkan compatibility layer that makes the same technology work on Linux. The layer is written by PancakeTAS, and the plugin credits the Lossless Scaling developers for the original frame generation technology. The plugin itself is a third party project: the documentation states plainly that it is an unofficial community plugin, independently developed and not officially supported by the creators of Lossless Scaling or lsfg-vk.

What the plugin adds is distribution and control. The lsfg-vk layer needs to be installed, pointed at the right games, and configured. Doing that by hand on a Steam Deck means working from a desktop shell and editing files, which is exactly the friction the plugin removes. Instead the plugin puts a settings panel into the Decky Loader menu, which is navigated with the controller from Game Mode.

The target hardware is the Steam Deck, and the plugin also works on SteamOS, Bazzite or any other Linux platform compatible with Decky Loader. The scope of what it does is narrow and concrete: install the lsfg-vk Vulkan layer, choose which games get frame generation, and expose the upstream lsfg-vk settings. Frame generation then activates when the running game's Steam AppID matches an assigned upstream profile, which means the selection is per title rather than global.

The project also describes itself as usable on SteamOS, Bazzite or any other Linux platform compatible with Decky Loader, so the Steam Deck is the common case rather than the only case.

Installing the plugin zip through Decky Loader

Installation is a download and a menu action, with no package manager involved. The steps are: take the plugin from the releases tab, download the `Decky LSFG-VK.zip` file to the Steam Deck, open Game Mode, use the settings cog in the top right of the Decky Loader tab to enable Developer Mode, go to the Developer tab, choose Install Plugin from Zip, and select the downloaded file.

The Developer Mode step is what the Decky Loader requires before it will accept a local archive, and it is the part people miss. The plugin itself is not installed from the plugin browser in that flow, and the documentation does not describe a command line alternative for the initial install.

There is a naming detail worth noticing, because it matters when picking a file from the releases list. The archive the user installs is `Decky LSFG-VK.zip`, while the payload inside it is the lsfg-vk layer itself, and that payload is fetched separately and pinned by hash. In the plugin manifest the remote binary is recorded as follows:

"remote_binary": [
  {
    "name": "lsfg-vk-2.0.0.tar.xz",
    "url": "https://builds.lsfg-vk.dev/lsfg-vk-2.0.0.tar.xz",
    "sha256hash": "08bdbdf373a111022df87dac7aa87e3b564bb841f961552e3ca85fea12b5aa74"
  }
]

So the plugin archive is small, and the heavier Vulkan layer arrives from the upstream build server at install time. The manifest records the expected SHA-256 hash of that download, which is the one integrity check in the whole chain and the reason the pinned `lsfg-vk-2.0.0.tar.xz` name matters when a newer upstream version appears.

The first run needs a Steam branch switch before it needs the plugin

The order of operations in the documentation matters, because the plugin cannot do the first part for you. Lossless Scaling has to be purchased and installed from Steam first, and then its Steam branch has to be switched: in the Lossless Scaling app, go to Properties, then Game Versions and Betas, then select the `lsfg-vk` branch and let Steam download the new version. That branch is the Linux capable build of the product that the Vulkan layer expects to sit in front of.

Only after that does the plugin become useful. The documented flow is to open the plugin from the Decky menu, click Install lsfg-vk to set up the Vulkan layer automatically, then configure the settings, picking either Default or a running or configured game and adjusting the upstream lsfg-vk options. Flatpak applications are handled separately, either one at a time in the Flatpak tab or in bulk with the Enable all and Remove all profiles actions.

The game profile model is the mechanism that ties the whole thing together. Frame generation activates when the game's Steam AppID matches an assigned upstream profile, so the plugin is not a global on/off switch but a mapping from Steam AppID to an upstream profile. That mapping is also why the Flatpak tab needs its own per application treatment: a Flatpak game is a different launch path from a native one, and the documentation gives the Flatpak tab its own bulk actions rather than folding it into the same list.

The last step is simply to launch the game, with the caveat that the running title has to be one the plugin has been told about.

The four core settings and what they trade away

The plugin exposes the upstream settings rather than inventing its own set, and the four documented controls are recognisable frame generation parameters.

FPS Multiplier sets the generation factor, with 2x, 3x and 4x offered. The trade is direct: every extra generated frame costs GPU time that the game cannot spend on its own rendering.

Flow Scale adjusts motion estimation quality, where lower values mean better performance and higher values mean better quality. It is the classic quality against cost dial, and it is worth knowing which way round it runs before changing it, since the wording puts performance first.

Performance Mode uses a lighter processing model, and the documentation recommends it for most games. It is the setting a user should leave alone first, because it is the one the project itself points at as the default choice for the majority of titles.

FP16 Acceleration uses half precision acceleration when the hardware supports it. The plugin only applies it when the hardware supports it.

Taken together these four controls are the whole tuning surface the plugin documents. There is no per game quality preset, no overlay, no frame time graph and no capture feature described, and the plugin does not add its own rendering pipeline on top of the layer.

A TypeScript frontend over a Python plugin with a justfile for the deck

The repository layout shows a conventional Decky plugin shape. The Python side is `main.py` with `py_modules/` for its modules, the frontend is `src/` built with rollup, and `plugin.json` describes the plugin to Decky Loader. TypeScript sources are configured by `tsconfig.json`, the frontend build by `rollup.config.js`, and `package.json` names the package `decky-lsfg-vk` at version 0.14.4.

The frontend dependencies are the Decky UI kit, `@decky/ui` and `@decky/rollup`, with React type definitions alongside them, and the runtime dependency on the plugin API is `@decky/api`. Icons come from `react-icons`. The manifest also pins the optional native rollup binaries for `linux-x64` on both glibc and musl, and lists `arm64` and `x64` as the supported CPU architectures, with glibc and musl listed as the supported libc variants.

Development is driven by a `justfile` rather than by raw scripts, and the recipes are short:

default:
    echo "Available recipes: build, deploy, test, clean"

The other recipes map to the underlying package manager commands, so `build` runs `pnpm build`, `test` runs `pnpm test` and `deploy` runs the deployment script in `scripts/`. The test command itself is interesting because it covers both halves of the plugin: the TypeScript tests run through the Node test runner, and the Python tests run through `unittest` discovery over the `tests` directory. The test files named in that script point at the parts of the plugin most likely to break silently, namely the Steam launch options, the now playing state and the game target resolution.

The `watch` recipe is worth a mention as a debugging aid, because it tails the system journal on a machine at a fixed local address over SSH, which is the quickest way to read plugin logs from a Deck while the plugin misbehaves.

The gaps a user has to accept: unofficial status and licence ambiguity

The first gap is support. The project is explicit that it is an unofficial community plugin, that it is independently developed, and that it is not officially supported by the creators of Lossless Scaling or lsfg-vk. Support runs through a Discord channel, and the credits list a large amount of community work around guides, testing and tutorial videos. That is a real but informal support model, and if the upstream layer changes shape, a community plugin is the first thing to break.

The second gap is the dependency chain. The plugin does not contain frame generation. It needs Lossless Scaling from Steam, it needs the `lsfg-vk` branch of that product, and it needs the upstream Vulkan layer that it downloads from the upstream build server. A change to the Steam branch, a withdrawn beta, or a change in the layer's configuration format all land on the plugin. The pinned `lsfg-vk-2.0.0.tar.xz` name in the manifest is a snapshot of one such coupling point, and the version history shows the plugin moving in step: v0.14.0 was released as the LSFG-VK 2.0.0 update.

The third gap is licence clarity. The licence field in the plugin manifest says BSD-3-Clause, while the licence recorded for the repository is a custom licence that GitHub cannot classify, with the LICENSE file holding the actual terms. Two different statements about the same project, in the same repository, is not something to resolve by guessing. Anyone who intends to modify the plugin, redistribute it, or ship it on a device they manage should read the LICENSE file and confirm the terms with whoever is responsible for compliance. This article does not give legal advice.

On activity, the repository is not archived, the last push was on 2026-09-17, and the releases v0.14.3 and v0.14.4 both landed that same day, with v0.14.1 shipped on 2026-09-13 for the 2.0.0 update. Recent activity is clear; a stated support window is not.

Editorial conclusion

Adopt Decky LSFG-VK if you own a Steam Deck or another Decky Loader compatible Linux machine, you already own Lossless Scaling on Steam, and you want the lsfg-vk layer installed and configured per game without touching shell commands. Do not adopt it if you want an officially supported integration, if your distribution is not Decky Loader compatible, or if a licence conflict between the BSD-3-Clause field in package.json and the custom LICENSE file blocks your distribution. Before installing, check the plugin release you download, the SHA-256 hash recorded for the bundled lsfg-vk archive, and whether the upstream Lossless Scaling branch still ships an lsfg-vk variant.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. xXJSONDeruloXx/decky-lsfg-vk on GitHub