Hi everyone,

I created decky-lsfg-vk-experimental and lsfg-vk-experimental.

They are forks based on someone else’s work, which I have built upon.

These projects began as forks of existing open-source work. I built on that foundation because I wanted more features.

You probably saw previous posts and I know that some of you have hard feelings about how I operate, but I wanted to take the time to clarify a few things. Please to take the time to read this post entirely.

I want to address two things: the release of a new engine called MAKO, and some of the discussion around how I develop software.

First of all, MAKO is here:

https://github.com/eugeniosegala/MAKO

It's the continuation of my work, and It includes everything in one package: a Decky plugin and a standalone renderer.

I realised that I would not be able to merge my experimental plugin into the upstream project, so I decided to build something independent (still based on previous code).

This is the next step.

The new MAKO release includes:

• Substantially improved performance for Adaptive Frame Generation
• Game-aware profiles
• Per-game support for Heroic, EmuDeck and other Flatpak applications
• New Proton compatibility options
• Loads of new options for frame pacing stability
• An improved Steam Deck interface

Regarding how I operate and what I have done so far:

You may like my work or not. That is fine. But it is undeniable that what I did made an impact.

The experimental plugin was downloaded more than 20,000 times in less than one week. It was also featured in YouTube videos from creators around the world (some of the biggest channels in the Linux gaming community), If interested, I tried to keep track of some of them here:

https://github.com/eugeniosegala/MAKO/blob/main/plugin/docs/FEATURED_IN.md

Now, about AI and the various critics.

Yes, I use it.

I have built game engines and games from scratch before this. That experience matters when working on rendering performance, frame timing, graphics systems, Vulkan, and stability under real conditions.

If you want to know more about my background, start with my GitHub (or search on Google) and look at the projects. You will get a sense of the calibre of work I do.

https://github.com/eugeniosegala

I use AI openly and extensively, but never blindly. This is not a prompt it and ship it process.

I decide what a feature needs to achieve, what constraints it must respect, what trade-offs are acceptable, and what evidence is needed before I consider it ready.

Agents help me work faster. They can explore implementation options, inspect code paths, write tests, add instrumentation, analyse logs, and narrow regressions.

They do not replace engineering judgement.

I review the code, including C++ and Vulkan changes. I review diagnostics, test results, and actual performance behaviour. I make the final release decision. I am responsible for what gets shipped.

As many of you have said (and to be fair, I'm receiving a significant volume of emails about this), Adaptive Frame Generation is a significant technical achievement. The hard part was not writing code that generates frames. The hard part was designing scheduling, safety limits, and recovery behaviour that works when frame rate changes, GPU load rises, an overlay appears, a game hitches, or the swapchain is recreated.

AI helped accelerate the work, but it did not define the problem or validate the result. I did.

The workflow I use is close to the event-driven development process I wrote about here:

https://eugeniosegala.dev/event-driven-development-for-ai-agents/

In practice, it is not one coding assistant in a terminal. It is a network of agents, conventional engineering tools, real devices, and virtual test environments.

Agents can coordinate tasks through webhooks, trigger specific scenarios, collect logs and performance metrics, and feed that evidence into the next investigation or implementation step.

I currently use a mix of coding agents, alongside normal engineering tools.

I do not think a percentage of AI-written code means much. An agent might draft routine implementation, or help solve one difficult edge case. In both cases, the architecture, technical reasoning, validation, review, and accountability are mine.

I am laser-focused on metrics and results. I do not work on this casually. If the data says something needs improving, I will investigate it and release a fix. That means MAKO may receive several releases in a single day.

If you use the plugin, keep an eye on it. It will evolve quickly.

Finally, on credit.

MAKO is an independent experimental project built on xXJSONDeruloXx’s original Decky LSFG VK plugin and PancakeTAS’s lsfg-vk layer. I want to thank xXJSONDeruloXx and PancakeTAS for the work that made these projects possible. There may be hard feelings about the situation, but there are none on my side. I respect the original work and I am giving credit for it.

As I discussed with Deck Wizard, I have also added an AI-use disclaimer to my projects:

https://github.com/eugeniosegala/MAKO/blob/main/AI_USE.md

MAKO is what I am focused on now. I will keep building it openly, measuring it properly, listening to users, crediting the work it builds on, and shipping improvements when the results justify them.

I have been working on this relentlessly. Now it is time to play some video games.

Cheers!

I get that most PS5 pro games can run a 4k (often is not 100% native) 60 fps and some at 120 fps as well..

However, on the Steam Machine I can usually run AAA games at 1440p and 120fps using the new experimental loss less scaling plugin for Linux. I'm one of the creators btw: https://github.com/eugeniosegala/decky-lsfg-vk-experimental (in case you are interested). But even without, perfs are quite good.

Now, if you don't like frame generation (however, keep in mind that the above is game changing in terms of ghosting etc..), the Steam Machine can run games at 1440p and 60fps, and you have your entire Steam game library... which is a huge pro compared to the PS5 store.

In general, I feel like the setup I achieved:

1440p at 120 fps with experimental frame gen (+ combined with FSR balanced) is better than 4k 60 fps (PS5) with some games at 120fps...

Overall, I can run more games at 120fps (or above 100) compared to consoles, and still be in the 1440p bracket (which honestly is quite good).

The Steam Machine requires some tinkering, but I haven't touched none of my other consoles since I bought it?

Often, I think there's a bit of a skill issue.

The Machine is good.

I upgraded the stock 512 GB Kingston SSD in my Steam Machine to a 4 TB Samsung 990 PRO, preserving SteamOS, installed games, settings, shader cache, saves, emulators, Proton versions, plugins, OS tweaks, and everything else on the original drive.

This guide is specifically about cloning: moving your existing installation to the new SSD while keeping everything as it is. If you have spent time configuring emulators, plugins, Proton, Desktop Mode tweaks, non-Steam games, and other personal setup (that list can get long very quickly)... you may be interested in this!

Some of the hardware information in this post (such as compatible SSDs, tools, and the physical installation process) may also be useful if you are doing a fresh install instead.

-----

IMPORTANT: IF YOU DO NOT NEED TO KEEP YOUR EXISTING STEAMOS INSTALLATION, GAMES, SETTINGS, SHADER CACHE, SAVES, EMULATORS, PLUGINS, OR OTHER LOCAL DATA, A FRESH STEAMOS INSTALL ON THE NEW SSD IS SIMPLER.

THIS GUIDE IS FOR PEOPLE WHO WANT TO CLONE THEIR CURRENT DRIVE AND KEEP EVERYTHING AS IT IS.

-----

Let's start...

This is the exact setup and method I used personally. My Steam Machine has now been running from the cloned SSD for several days, including normal gaming, without issues. SteamOS booted normally and recognised the expanded storage.

I am sharing the parts that worked for me, not guaranteeing that every SSD, enclosure, or tool from another brand will work identically. If you use alternatives, confirm physical size, connector type, enclosure support, clearance, and power requirements yourself.

What I used

• SSD: Samsung 990 PRO NVMe M.2 SSD
  • NOTE: I used the 4 TB, no-heatsink version and can personally confirm it fits and works in this Steam Machine. Other capacities in the same range may work, but I only tested this specific 4 TB model. I cannot confirm that the version sold with Samsung’s integrated heatsink will fit, as internal clearance may differ.
• Clonezilla USB drive: SIMMAX 16 GB USB flash drives
• NVMe enclosure: UGREEN 10 Gbps M.2 NVMe enclosure
• Recommended screwdriver kit: iFixit Mako 64-bit precision driver kit
• Work mat/organiser: magnetic repair mat
• Gloves: nitrile gloves
• Physical SSD replacement guide: iFixit Steam Machine (2nd Generation) M.2 SSD replacement

The Mako kit is worth recommending because it includes the T8 bit for opening the machine and a 5 mm nut-driver bit for moving the M.2 standoff. The standoff is the small threaded spacer beneath the SSD mounting screw.

NOTE: All the above tools are necessary to perform the cloning end-to-end (you will need less with a fresh Steam OS install, however, they will come handy in other modding scenarios later on, in case you want to touch the Steam Machine again! (i.e: swapping Ram, opening controller etc..).

Important: complete the reserved-space adjustment

After a successful -k1 proportional clone, do not stop at the first successful boot (PAY ATTENTION TO THIS SECTION). On this SteamOS layout, the larger /home ext4 filesystem can carry over a percentage-based reserved-block allocation from the original drive.

On my 512 GB to 4 TB clone, this made the reserve grow from roughly 15 GiB to 109 GiB. Steam displayed much of that unavailable-but-empty capacity as "Non-Steam/Other storage".

The reserved space does not contain games or files, and it does not grow exponentially (it scales proportionally with the size of /home). Complete Section 8 after confirming the cloned SSD boots normally to reset the reserve to a sensible fixed 15 GiB and make that capacity available to Steam.

1. Prepare the Clonezilla USB

1. Download Clonezilla Live.
2. Select:
   • CPU architecture: amd64
   • File type: iso

amd64 is correct because it is the architecture of the Steam Machine.

1. Download balenaEtcher.

Download the Etcher version that matches the computer creating the USB:

• Apple Silicon Mac (M1, M2, M3, or later): Etcher for macOS (ARM64)
• Intel Mac: Etcher for macOS (x64)
• Windows PC: Etcher for Windows (x86|x64) Installer

1. Insert the USB flash drive.
2. In Etcher:
   • Select the Clonezilla .iso
   • Select the USB flash drive
   • Click Flash
3. After flashing, macOS may say: “The disk you attached was not readable by this computer.” This is normal because Clonezilla uses Linux partitions that macOS does not recognise.

Click Eject. Do not initialise, erase, or format the USB.

2. Connect the new SSD

1. Put on the nitrile gloves if you have them.
2. Place the Samsung 990 PRO into the UGREEN NVMe enclosure.
3. Connect the enclosure directly to a rear USB-C port at the back of the Steam Machine if possible.

A rear USB-A 3.x port also works with the correct cable/adapter, but USB-C is preferable for speed. Avoid hubs during cloning.

1. Connect the Clonezilla USB.
2. Connect a wired keyboard.

3. Boot Clonezilla

1. Turn on the Steam Machine.
2. Repeatedly press Esc during startup.
3. In the boot menu, choose the Clonezilla USB / UEFI USB device.
4. Select the default Clonezilla boot option.
5. Choose your language and keyboard layout.
6. Select Start Clonezilla.

4. Select the correct clone mode

Choose:

• device-device (work directly from one disk to another)
• Beginner
• disk_to_local_disk

Clonezilla will then ask for a source disk and target disk.

For my system:

• Source: nvme0n1 (476.9 GiB Kingston internal SSD)
• Target: sda (3.6 TiB Samsung SSD 990 PRO in the USB enclosure)

Your device letters may differ. Do not rely on the letters alone: verify the model name and capacity.

Use Space to mark a drive, then Enter to continue.

Important: the target drive is erased. The Samsung 990 PRO must be the target; the internal Kingston SSD must be the source.

5. Clonezilla options

For the source filesystem check screen, leave the default selected:

-sfsck — Skip checking/repairing the source filesystem

Press Enter.

Important: choose -k1

At the partition-table screen, select:

-k1 Create partition table proportionally

Then press Enter.

This is important. -k1 proportionally expands the cloned partitions to use the larger SSD. If you leave it on -k0, the cloned installation may retain the original 512 GB-sized partitions, leaving most of the new SSD unused.

Clonezilla documents -k1 as its proportional partition-table option; it also enables filesystem resizing. Clonezilla documentation

For the remaining prompts:

• Log files: choose No
• Finish action: choose poweroff
• Confirm the target disk twice by typing y

Then leave Clonezilla alone. It may take a while, particularly when copying the large home/game-data partition.

Possible post-processing warning

After the partitions have cloned, Clonezilla may run post-processing steps such as rebuilding the boot/initramfs configuration and updating the EFI boot entry.

On my Steam Machine, Clonezilla displayed warnings similar to:

Failed to create initrd in the restored OS
Read-only file system
chroot: failed to run command

This occurred during Clonezilla’s post-processing stage, after it had reported that the individual partitions had cloned successfully. It did not mean the disk copy itself had failed.

Clonezilla also found the SteamOS EFI boot file:

Found Boot file /EFI/steamos/steamcl.efi

and completed the restore. The cloned Samsung 990 PRO then booted SteamOS normally, with my games, settings, and expanded storage intact.

Do not interrupt the process if you see these messages. Let Clonezilla finish completely. Consider the clone successful only if it reaches:

Finished!
ocs-live-general finished

The post-processing warning may cause Clonezilla to return to a command prompt instead of shutting down automatically. If that happens, run:

sudo poweroff

For extra peace of mind, you can boot the Steam Machine once more with the original SSD still installed and confirm SteamOS works normally before starting the physical SSD swap.

BEFORE YOU PROCEED: Disconnect the power cable, Clonezilla USB, SSD enclosure, and any other USB devices. Remove any microSD card too; leave nothing connected before opening the Steam Machine.

6. Physically install the SSD

1. Disconnect power from the Steam Machine.
2. Disconnect the Clonezilla USB and the enclosure.
3. Use the magnetic organiser mat to keep screws organised.
4. Follow the iFixit physical replacement guide.
5. Use the T8 bit from the Mako kit to open the unit.
6. Move the M.2 standoff to the 2280 position if needed. Use the 5 mm nut-driver bit rather than pliers.
7. Install the Samsung 990 PRO and secure it with the SSD screw.

Note: Leave the Samsung label in place. It is part of the drive’s heat-spreader design, do not peel it off!

7. First boot and confirmation

Boot the Steam Machine and SteamOS should load normally with your games, settings, and library intact.

Check:

Settings > Storage

Mine shows roughly:

3.5 TB total
3.1 TB free

This is expected. SSD manufacturers advertise decimal terabytes, while operating systems use binary units; SteamOS also requires system partitions and filesystem metadata.

8. Storage size and ext4 reserved-space adjustment

As mentioned at the beginning, this section is very important, as SteamOS will report a surprisingly large amount of unexplained “Non-Steam” or “Other” storage after the clone.

There are two separate things happening:

1. -k1 proportionally enlarges the cloned partitions so the larger SSD can be used.
2. The ext4 filesystem used for /home may reserve a percentage of its free space for privileged system processes.

On a 512 GB drive, that reserve is fairly small in absolute terms. On a 4 TB drive, the same percentage can become more than 100 GB.

This does not mean the clone failed. It is free space that ordinary applications such as Steam cannot use.

First, open Konsole in Desktop Mode and measure it (this script does not change anything, it's just a measurement script):

python3 - <<'PY'
import os

path = "/home"
stats = os.statvfs(path)

unit = stats.f_frsize
gib = 1024 ** 3

total = stats.f_blocks * unit
allocated = (stats.f_blocks - stats.f_bfree) * unit
available = stats.f_bavail * unit
unavailable = (stats.f_bfree - stats.f_bavail) * unit

print(f"Filesystem total:       {total / gib:10.2f} GiB")
print(f"Actually allocated:     {allocated / gib:10.2f} GiB")
print(f"Available to Steam:     {available / gib:10.2f} GiB")
print(f"Reserved/unavailable:   {unavailable / gib:10.2f} GiB")
PY

My initial result was approximately:

Filesystem total:        3631.38 GiB
Actually allocated:       359.08 GiB
Available to Steam:      3163.00 GiB
Reserved/unavailable:     109.30 GiB

A small reserved amount is normal. In my case, approximately 109 GiB was unnecessarily large.

Reduce the reserve to a fixed 15 GiB

Only do this after your cloned SteamOS installation has booted successfully.

If sudo asks for a password and you have not created one for the deck account, run:

passwd

Then run this script:

DEV="$(findmnt -n -o SOURCE --target /home)"
FSTYPE="$(findmnt -n -o FSTYPE --target /home)"

echo "Device: $DEV"
echo "Filesystem: $FSTYPE"

if [ "$FSTYPE" != "ext4" ]; then
    echo "STOP: /home is not using ext4."
    exit 1
fi

BLOCK_SIZE="$(
    sudo tune2fs -l "$DEV" |
    awk -F: '/Block size:/ {
        gsub(/[[:space:]]/, "", $2)
        print $2
    }'
)"

if [ -z "$BLOCK_SIZE" ] || [ "$BLOCK_SIZE" -le 0 ]; then
    echo "STOP: Could not determine the filesystem block size."
    exit 1
fi

TARGET_GIB=15
RESERVED_BLOCKS=$((TARGET_GIB * 1024 * 1024 * 1024 / BLOCK_SIZE))

echo "Block size: $BLOCK_SIZE bytes"
echo "Setting reserved space to approximately $TARGET_GIB GiB"
echo "Reserved-block count: $RESERVED_BLOCKS"

sudo tune2fs -r "$RESERVED_BLOCKS" "$DEV"

This script:

• Identifies the filesystem mounted at /home
• Stops unless it is ext4
• Reads the real filesystem block size
• Calculates the correct reserved-block count for 15 GiB
• Changes only the amount of otherwise-free capacity reserved for privileged processes

It does not delete, move, or alter games, saves, shader caches, Proton prefixes, or SteamOS files.

Run the measurement script again to verify the result. Mine changed to:

Filesystem total:        3631.38 GiB
Actually allocated:       359.11 GiB
Available to Steam:      3257.26 GiB
Reserved/unavailable:      15.02 GiB

That released about 94 GiB to Steam and other normal applications.

Fully exit and reopen Steam, or reboot once, before checking:

Settings > Storage

Finally, launch a few games and confirm everything works normally.

I hope this guide was helpful!

Cheers!

Hi everyone,

I’ve released an experimental Decky LSFG-VK plugin that brings the current lsfg-vk v2 developer build to Steam Deck / SteamOS users.

Release/download:

https://github.com/eugeniosegala/decky-lsfg-vk-experimental/tags (download the latest tag)

A bit of context on why I made this:

As of 30 July 2026, the public Decky plugin’s lsfg-vk build is 140 commits behind the latest upstream "develop" branch (this is mostly because lsfg-vk, which is also the library used by the Decky LSFG-VK plugin, hasn’t released a new version in a while, keep in mind that I'm using a develop build).

This experimental plugin instead packages the reviewed, checksum-verified "lsfg-vk 2.0.0-dev28" developer prerelease of the engine lsfg-vk (released a month ago). It is not a rolling download: each plugin release pins and verifies a specific upstream archive.

In my own testing, I’ve had very good results:

- Noticeably less ghosting in some games; in a few cases it is barely noticeable.

- FP16 (new option) can improve performance on supported AMD GPUs.

- I suggest starting with Performance Mode disabled. Performance Mode is faster, but the full-quality mode in this v2 developer build looks substantially better than lsfg-vk v1 in my testing.

- That said, this is still a developer build. Some games may regress, fail to attach, or simply work better with the public/original plugin. Please test it game by game.

It is designed to coexist with the original Decky LSFG-VK plugin. The experimental version has its own private install, config, and wrapper, so you can keep both installed and choose one per game:

- Original/public plugin: "~/lsfg %command%"

- Experimental plugin: "~/.local/bin/lsfg-vk-experimental %command%"

Use exactly one wrapper per game; do not combine them.

Huge thanks to Kurt Himebauch / xXJSONDeruloXx for the original Decky LSFG-VK plugin, and PancakeTAS and contributors for lsfg-vk. This is an independent experimental fork, not an official.

Full repo: https://github.com/eugeniosegala/decky-lsfg-vk-experimental

I’m also working on a completely new plugin using a new frame-generation model for Linux/SteamOS, so keep an eye on the repository! 🙂