MTP Ecosystem
A personal operating system for my desktop — window manager, lock screen, wallpaper, settings, widgets and a terminal, all written in Rust
I replaced my Linux desktop with something I wrote. This page is what that turned into.
What it is
Most “custom Linux desktop” projects are a pile of configuration files. This is not that — it is programs.
There is a window manager. There is a lock screen that asks for a real password through PAM, the same system call a distribution uses, so it works with real user accounts. There is a wallpaper engine. There is a settings application with a GUI. There is a terminal. And there are widgets and a launcher that talk to each other over a local socket.
Together they are an operating-system-shaped thing that I use every day, sitting on the actual Wayland compositor stack rather than replacing the kernel or the graphics driver.
What it does
- A window manager on Smithay, the reference Wayland compositor library, talking to DRM/GBM directly with a wgpu renderer for what the GPU draws.
- A lock screen that genuinely locks. Password verification through PAM — not a comparison against a stored string — plus screen dimming and session handling.
- A wallpaper engine that composites backgrounds and can animate them without reloading the framebuffer each frame.
- A settings app in GTK4/libadwaita, so configuration is not something you do by editing text files.
- An RTL terminal emulator — Persian text, right-to-left rendering and input, which most terminals handle badly.
- Widgets and a launcher sharing a local socket protocol.
The numbers
| 96,500 | lines of Rust |
| 326 | source files |
| 4 | binaries in the main workspace |
| 1 | separate workspace for the browser extension |
Why it’s worth a look
The reason to write a desktop is that you stop being a user of the tools and start being someone who has to live with the consequences. Doing PAM properly meant accepting that my lock screen is now a security component, so a mistake has real consequences — that changes how you write the code. Doing DRM/GBM means accepting that the compositor has a hardware dependency and a timing dependency, and that a compositor that misses a frame deadlocks.
This is also the project where I most clearly had to design for other people: settings have to be discoverable without documentation, and the widget socket protocol has to make sense to a program I had not written yet.
Current state
- It is my own machine, not a distribution. I have not tried to make it work on hardware I do not own, so I cannot tell you how portable it is.
- Battery management is effectively missing. Power profiles are not wired up; on a laptop that is a real limitation.
- The Chromium extension is a separate workspace and is the least finished piece.
The gap between this and a finished desktop product is large, and I am more comfortable saying that plainly than implying the work is finished.
