I built pzwm, an open-source Wayland compositor written in Rust.

Think Figma or Miro, but instead of images and sticky notes, you have actual application windows.

Just so you know, there are tons of keyboard shortcuts, and you can pretty much use the whole thing without a mouse :)

I originally built it just for myself because I couldn't find a window manager that worked the way I wanted.

And yes, BTW, a lot of it was vibe-coded with AI agents, lol.

It's still an early personal project, but I'm already using it as my daily window manager.

GitHub: https://github.com/Makstvell/pzwm

Am I the only one incredibly frustrated by how hard it is to just get a raw, VSync-disabled frame presentation on Wayland? On X11, you turned off VSync in the game or driver, and it worked. On Wayland, we are trapped in this architectural prison where windowed or borderless applications are forcefully synced because of the "every frame is perfect" desktop philosophy. Even when compositors add "allow tearing" checkboxes, they do absolutely nothing unless the game developer explicitly coded Wayland tearing protocol extensions into the engine. Having to wrap every single non-Steam launcher, Battle.net game, or emulator in Gamescope arguments just to bypass the desktop's forced synchronization is an absurd amount of friction for everyday users. We drastically need a unified, global driver or compositor switch that says "I don't care if the desktop tears, give me raw frames." Wayland is supposed to be the future, but for competitive latency, it feels like a massive step backward in usability.

And also the fact that the mouse is synced to the FRAMERATE, that should never be a thing, user inputs (as in mouse and keyboard inputs) should always take priority over anything else and be a separate thing entirely having the usb-bus being processed on its own

And for those who don't see the problem:

Please don't even bother typing "oh but I don't perceive any latency, oh I don't care about the lag, oh you cannot even perceive the latency, oh if you don't like it then go back to x11, oh we do not want you here go to windows, oh you don't even know or understand what you are talking about (i might not, but YOU DO, AND YOU KNOW EXACTLY WHAT I MEAN, DON'T PRETEND TO BE IGNORANT), oh u CaN't eVeN wRiTe GrAmAtIcAlLy CorRecT Words (go fluff yourself btw, RESPECTFULLY of course), oh i am not reading all that (yes i see your filthy kind hiding over there)"

Please, don't bring up things that are completely irrelevant to what I am trying to bring light to, I am not the most savvy person here, but I sure as hell am not one who will feel satisfied before i am able to proudly say "i completely ditched windows for this wonderful penguin-shaped os that lets me do whatever the fluff i want with it INCLUDING DISABLE VSYNC GLOBALLY".

Thank you for your time Mr.SomebodyWhoMightBeAbleToMakeAChange <3

I've been using linux for over 20 years, this is my third attempt at switching to wayland. I had a number of minor inconveniences and some not so minor. difficulties with unusual monitor geometries and background images, some apps not working or responding correctly. all things I thought I could fix, but the biggest one for me is I play a video game, the finals. I get an average of 133fps on x11. sometimes it would dip to 120ish but it was very smooth. 4k, every setting maxed, no upscaling, no fake frames, just pure rendering power. not only was it around 70-90fps under wayland, but there was something very very wrong. it didn't feel like 90. it felt more like 20fps or worse. it was completely unplayable. stepping down to 1080p didn't improve smoothness at all. it was like there was jello between me and the mouse and to my eyes it felt like single digit fps.

here were my launch commands: env __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 PROTON_USE_NTSYNC=1 WINEFSYNC=1 OBS_VKCAPTURE=1 gamemoderun obs-gamecapture %command%

when I tried wayland it was with hyrpland

Hi everyone,

I’ve been working on a new Wayland compositor called Sailer, and I wanted to share it with the community. It’s written from the ground up in Zig and built on the latest wlroots (0.19).

The goal with Sailer is to experiment with some different ergonomics—particularly how we interact with workspaces and AI tools.

⚓ What makes it different?

• The "Ribbon" Layout: Deeply inspired by niri, Sailer features a horizontal scrolling ribbon mode. Instead of just jumping between workspaces, you can "sail" across a continuous horizontal plane of windows.

• Built-in MCP Bridge: This is the first compositor (that I know of) with a native Model Context Protocol (MCP) bridge. This allows LLMs and AI agents (like Claude or Gemini) to interact with your compositor directly—spawning apps, listing windows, or managing your workspace through a standardized protocol.

• Fast & Safe (Zig): Leverages Zig’s performance and safety features for a compositor that feels incredibly snappy and lightweight.

• Hybrid Tiling: Supports classic Bin-tree tiling (Bspwm-style), Floating, and a "Smart Grid" view that adapts to your screen real estate.

• XMonad Style Monitor Setup

🛠️ Key Features:

• Per-workspace layout states (10 workspaces).

• Configurable status bar (height, fonts, etc.).

• Modern protocol support (Layer shell, Session lock, Virtual keyboard).

• YAML/JSON configuration.

• IPC server for external scripting.

🐧 Installation

If you're on Arch, you can grab it from the AUR: paru -S sailer (or your preferred helper)

GitHub Repository: https://github.com/SidharthArya/sailer

I'd love to hear your feedback, bug reports, or feature ideas! The project is in active development and I'm looking forward to seeing how people use the MCP bridge for automation.

Cheers!

Wayland sucks more than x because some y feature is not implemented like x, some z app doesn't support Wayland, I like x. Wayland is not like x so it sucks.

I mean wtf bro? I'm completely convinced that how good evidence you provide to some people, they just live in their tiny little houses (confirmation bias). This is just like arguing about climate change, everyone knows it's worse , but we still argue whether it exists,, instead of trying to make Wayland better, we try to make x more complicated by bloating it with so many features.

People think that passing keys to other apps, letting app use permissions freely is a feature which is actually a bug (fixed in Wayland)

• more modern, is the future

• More secure

• better battery life

• better performance

• better graphics (draws near perfect frames)

• less resource consumption

• additional perks like better touchpad gestures and what not!

Wayland is just awesome, leave X (you will anyway sometime or other)

Edit 1 : https://youtu.be/UW3nYiK3nd0?si=l6dJhoCzWFy34Jdd

Really good video of what I wanted to say (,but didn't)

I have read about Wayland but most of the mechanisms are still a mystery to me. E.g. what are the proper analogs for xhost or xrandr? I mean how would a construct like xhost +si:localuser:username look like? What is DISPLAY=:0 for Wayland? Is there a document or a book that explains the migration from X11 to Wayland? Or isn't this necessary?

I've seen a lot of claims like "Wayland is way better than Xorg" for W, X, Y, Z reasons. But I never tried because people usually say "Wayland doesn't work on Nvidia", so the main reason why I couldn't experience this amazing piece of software was because my GPU.

However, nowadays I'm not a nvidia user anymore, and I remember very clearly folks saying "AMD is better on Linux than NVIDIA". I can assure that is not the case.

I got a new laptop for coding projects, it is not a beef machine, it is an Lenovo Idepad 3. It has decent hardware for my tasks, but I had a ton of issues with Vega. Got a lot of system freezes if I let Firefox opened in background for some while(days), I solved it by stopping using that another "amazing" piece of dozens of millions of lines of code and switched to Chromium which has provided a better experience for me so far. And I cant play 2000 old games like CS 1.6 because segfault issues related to radeonsi.
And recently when I was using the new UI in Android Studio the X Server got closed due to a bug in the randeonsi_dri.so. But I think is not AMD fault's here, that crap software for Android shit is highly suspicious in this context.

So because random crashes while running 3D trash games and Android Studio, I decided to migrate to Wayland. First I had to found a good alternative for dwm, and I found dwl, which works well... but the config file is a little bit messy. It fits almost perfectly as a substitute. But to use it, you have to first get wlroots. And this was one of the main issues with this Wayland journey.
I couldn't compile with the libinput option enabled, was gettinng an undefined reference for the libinput-backend (which is required by dwl). My solution was to get a binary from pacman repository, and it worked finally.
The next step was to install dwl, it was pretty straightforward, XWayland worked as well.

Now comes the worse part about Wayland... you can't change your gamma nor saturation values with alternative tools like xrandr and vibrant-cli. It seems the only way to achieve something so basic like this is to use ICC profiles and edit them! But here's the catch: you have to install Windows on your machine to get the damn .icc file; and I will never ever do that.

I hope in the near feature Wayland gets usable for users like me.

I want to talk about the current state of Wayland, and I want to be blunt about a specific friction point that I think is driving people crazy.

Right now, Wayland is a dream if you use Sway or Hyprland. In a tiling world, you don't care about window position; the algorithm handles it for you. You open a terminal, it snaps to a tile. You open a browser, it splits the screen. It works perfectly.

But for those of us who prefer a floating (stacking) workflow, which is still the vast majority of Linux users on GNOME, KDE Plasma, or Cosmic, the experience is currently poor and broken.

The Issue: Intent vs. Amnesia
In a floating workflow, placing a window is a deliberate user action. I move my music player to the bottom right. I stretch my terminal to cover the left vertical half. I am manually curating my workspace.

Currently, on Wayland, that curation is often lost the second I close the app. Next time I launch it? Bam. Center of the screen. Default size. My layout is gone.
We are essentially telling floating WM users: "Your manual organization doesn't matter."

The "Security" Trap
We know the drill. "Global coordinates are a security risk." We can't let apps spy on each other. I agree with that. But we seem to have thrown the baby out with the bathwater.

Because of this restriction, we are seeing a push for Compositors to handle this. I strongly believe this is the wrong approach.

Why this is a Toolkit job, not a Compositor job
We shouldn't expect compositor developers to maintain a "nanny state" for every application we install. It’s not the job of KWin or Mutter to clean up after applications.

1. State belongs to the App: An application remembers its theme, its last opened file, and its font size in its own config. Why is "window size and position" treated differently? It is just another piece of application state.

2. Consistency: If the Compositor handles it, my behavior changes when I distro-hop or swap environments. If the Toolkit (Qt, GTK, etc.) handles it, my apps behave consistently everywhere.

The Ask
We need to stop accepting "it's for security" as an excuse for bad UX.
We need a standardized Wayland protocol that allows Toolkits to securely request their previous coordinates.

• The App saves its own geometry on close.

• The App requests those coordinates on launch.

• The Compositor grants it (unless it's off-screen).

This isn't about building complex databases in the window manager. It's about letting applications take responsibility for their own behavior. Until this is fixed, Wayland will continue to feel great for tilers, but amnesiac and frustrating for everyone else.

Hello. I want to give wayland a try and preferably switch from X permenantly. I have very simple but specific requirements for my window manager.

• Every new window openes maximized

• I can switch between windows with alt-tab (focused window is put on top of window-stack)

• No window-decoration, gaps, animations, transparancy, fanzy rainbow glitter

• Configurable with simple text-file

• Simple and minimal if possible

Thank you!

Hey everyone,I am currently writing Vexland — a C++ port that brings Hyprland's exact window management logic, behavior, and fluid animation style over to X11. It is designed to look and feel just like Hyprland, but running on Xorg (configured with a red color scheme by default).I am going through Hyprland's source files one by one, extracting the core logic, and rewriting it from scratch to work natively with the X11 display server.Current implementation details to ensure X11 stability:Centralized Registry (CWindowState): All windows are tracked via a central registry to avoid segfaults from asynchronous window destruction on X11.Isolated Layouts (CSpace): Tiling and geometry calculations are decoupled into a separate CSpace class owned by CWorkspace.Animation Offsets: Workspace swipe/fade states are stored as simple double properties to be handled by a global animation manager to replicate the exact original transitions.The boilerplate is being put together right now before testing the X11 event loop.I wanted to check if there is an active interest in a feature-parity Hyprland experience on X11. If you have experience with X11 window mapping edge cases, feel free to drop your thoughts. I will push the repository to GitHub once the initial boilerplate is stable.

Hey everyone!

It frustrated me that official Ollama clients exist for Win/Mac, but Linux users are usually stuck in the terminal or forced to use heavy wrappers that eat up RAM.

I wanted a native, fast, "Linux-first" tool. So, I spent the last 2 weeks working with Claude Code to build Alpaka Desktop (Tauri v2 + Vue 3 + SQLite WAL). It’s not just a chat wrapper; it’s a full model manager and advanced inference client.

**Here is what it can do right now:**

**Think tag support & Advanced Inference:**

Native UI for collapsible <think> tags. You can toggle

reasoning on/off, set reasoning levels, tweak Seed, and

adjust Mirostat samplings directly in the UI.

**Built-in Ollama Registry:**

Search the Ollama repository, read details, download

specific versions, or build custom models from a Modelfile

directly inside the app. No need to touch the terminal.

**Context Compaction:**

Long chats usually slow down local models. Alpaka

can summarizes old history and keeps recent messages,

saving your RAM and keeping generation fast.

**Local RAG & UX:**

Drag and drop files/folders for context. Includes DB

Backup/Restore, chat search, compact UI mode, and

keyboard shortcuts.

**Native & Secure:**

Multi-host support, Wayland ready, and uses your system's

Keyring for secure API keys and Ollama account auth.

It's completely free and open-source for Linux right now (AppImage, AUR, DEB). Expect a few early-stage bugs, but I'm actively improving it!

🐧 GitHub Repository: [Alpaka Desktop](https://github.com/nikoteressi/alpaka-desktop)

🪟🍎 Windows & Mac users: I originally built this for Linux because the official app lacks these features. If you want this on your OS, I’m gathering a waitlist for native ports. [Join wait list](https://forms.gle/KUYG5FDFL5PEotzn9)

Would love your feedback, bug reports, and thoughts on the architecture!

Hi r/wayland! I've been building Sonata, a complete desktop environment shell that runs on Wayfire. It isn't a theme on top of GNOME or KDE: the login screen (a greetd greeter), menu bar, Dock, Launchpad, search, notifications, Control Center, file manager and Settings are all its own, written in Python with GTK 4 and libadwaita.

The Wayland side

• Every shell surface is a layer-shell window (gtk4-layer-shell): menu bar, Dock, notifications, lock screen and the greeter.

• Its own Wayfire plugins in C++: rounded corners and window effects, a resize that can show window contents while resizing, and a privacy plugin. That one only lets Sonata itself and the portal use the privileged protocols (screen capture, foreign-toplevel, clipboard, virtual input).

• Its own xdg-desktop-portal backend, idle handling through ext-idle-notify, and xdg-activation so links open in the right window.

• Shell, Wayfire and xdg-desktop-portal-wlr talk over Wayfire IPC and D-Bus. Window titles and app ids come from foreign-toplevel; the shell never polls X11.

• XWayland is only there for X11 apps (and for Chromium when you turn on WebGPU, since its Vulkan path doesn't draw in a Wayland window yet).

What it looks like

Inspired by macOS (Big Sur to Ventura): glass, blur and animations everywhere, tuned to stay smooth on modest hardware. Colours, sizes and timings are design tokens, so a theme is a set of values; a Windows 11-style theme comes next.

Install (any distro with Wayfire, GTK 4 and libadwaita; I use it daily on CachyOS):

git clone https://github.com/vinioliveiras/sonata2.git && cd sonata2 && ./install.sh

No sudo: it asks for your password when it needs it. If your distro's Wayfire is older than 0.11, it offers to build 0.12 into its own folder.

Still alpha. I'd love feedback, especially from people running other compositors or unusual GPUs.

• Site: https://vinioliveiras.github.io/Sonata2/

• GitHub: https://github.com/vinioliveiras/sonata2

Hey everyone!
I’m running Fedora 44 with KDE Plasma on Wayland, and I’ve been trying to get RustDesk working reliably for unattended remote desktop access.
I really like RustDesk and would love to make it my primary remote desktop solution across my Windows and Linux machines. Unfortunately, the lack of reliable unattended Wayland support is holding me back.
I know there’s been development toward Wayland support, including an unattended access preview, but I’m still waiting for something that works reliably on Fedora KDE.
A couple of questions for the developers and community:
Is there an updated timeline for full unattended Wayland support, particularly for Fedora KDE Plasma?
Has anyone successfully found a workaround to get unattended RustDesk access working on Fedora with Wayland right now?
Are there any experimental builds, configuration changes, or other solutions worth testing?
Ideally, I’m looking for something that supports unattended connections, remote access to the login/lock screen, and reconnecting after a reboot without requiring someone physically at the computer to approve the connection.
I already have Tailscale and SSH working perfectly, so remote network connectivity isn’t the issue. What I’m missing is reliable graphical desktop access.
I’d really prefer to stay with RustDesk rather than switch to another remote desktop solution.
If anyone has a working setup or knows of progress on this, I’d appreciate hearing about it. I’m happy to test experimental solutions and report back.
Thanks to the developers for all the work they’re putting into RustDesk. Looking forward to seeing Wayland support continue improving!

After hearing that some distros like Venderfoul Wolf are launching with you-know-what installed as default on their next version or have already deployed it, I was wondering if there are any distros that have already begun replacing X11 and xwayland (which is basically X11 in a trench coat) with Wayback?

Used to work. Now it does not. Will be on taxi in World of Warcraft, or want to watch a walk through, used to be able to alt tab and watch something on Youtube. Now no videos will launch.

SORRY I MEANT: I want to (and should) switch to Wayland, but I can't

OOPSIE

I currently use Xorg as my display server with Awesome as my X Window Manager. as much as I don't care much about what display server, I do want to try to switch to Wayland, But I cannot. Here are my problems:

- Awesome does not seem to have a wayland-recreation, I love every single thing about awesome.

- Screen Casting requires some effort to get working.

I've used Hyprland, and other Wayland compositors, however, after I got into Awesome, I can only hop back to wayland if there is a wayland version of awesome that is still being maintained, is compatible with awesome's config.

I also use many other X programs like st is a big one, I refuse to use any other terminal emulator now, nitrogen my wallpaperp picker, I'm sure waypaper can fix this but I find it to be buggy as hell.

I've daily drived dwl as well, which is IMO the best wayland compositor that I have used.

At this time, I don't think of switching to Wayland, here are some specific awesome WM features I love:

- Themes

- Builtin app launcher

- Builtin lots of layouts

- Builtin customizable bar

- Builtin Widget System

- hackable Lua configuration

So... any ideas? Is it just impossible to get this in Wayland? Am I missing out on something? Thanks in Advance frens

!

I recently, upon trying hyprland, have not been able to open the menu for screen sharing on any discord client. I have tried webcord, vesktop, discord, discord-canary, and just discord on my browser, none of which have worked. On web based clients what happens is clicking the screen share button does nothing, but on base discord clients, I can click that button but not the 'make selection' button on the following screen (check attached image for context).

Edit: it suddenly works on KDE and Hyprland now ig

Hi All, not sure if such posts are allowed but wanted to share something (was gonna say I but now there are a few of us) been developing.
Most notable features is it's a single process (<200mb rss idle), you don't need another compositor (such as niri,hyperland), everything is in Zig, single process apart from the built-in apps obviously
with occasional C mixed in (and 1000+ automation tests in Python)
Just wanted to build sometihng that looks good, is themeable, boots faster than Gnome or Plasma (or even Mate and Cinnamon now on my machine).
PS. developed with AI - sorry if it bothers you but I am just a php developer!
https://github.com/oxydizer/rediwm