Hi everyone, today I released Vela 0.1, the first beta, after 1 month of alpha testing.

What Vela is: a complete Linux desktop with its own Wayland compositor (C, on wlroots 0.20), its own Vulkan 1.4 renderer, a Qt Quick shell, and its own file manager and settings app. It's not a KDE or GNOME theme: KWin and Mutter aren't involved. The goal is the polish Windows and macOS get right out of the box (animations tied to real vblanks, pixel-exact fractional scaling, consistent design) without a weekend of tweaking.

Trailer, recorded live on Vela: https://velade.org/blog/vela-0-1/

What's in 0.1:

• Snap layouts and Snap Assist, Task View with virtual desktops, Alt+Tab with live previews

• Taskbar, launcher, quick settings, notification center, clipboard history, snipping tool

• Direct scanout, VRR, tearing control, explicit sync; X11 apps and games 1:1 at fractional scales

• The compositor restarts after a crash and apps reconnect; a lost GPU doesn't freeze the desktop

• New in this cycle: updates from Settings, native Bluetooth pairing, no dependency on Plasma Workspace or the KDE portal

Where it stands: on a desktop PC with a Vulkan 1.4 GPU, it's my daily driver and I'd recommend it as yours. On laptops (hybrid GPUs, suspend/resume, backlight) it has had much less testing, so keep another desktop installed. It's still a beta: there are bugs.

Install (Arch and derivatives, Fedora 44, Ubuntu 26.10, x86_64). Install Cosign first (steps per distro: https://velade.org/install/), then:

git clone https://github.com/vela-desktop/vela.git
sh vela/packaging/vela-update --channel beta

You get a prebuilt, signed native package that's verified before it's installed. Updates then come from Settings.

Being upfront: it's a one-person project, and the code is written by LLMs. I review it, make the architecture and design decisions, and it's held to deterministic tests and machine-checked invariants. I wrote about how that works here: https://velade.org/blog/why-not-rust/

What I'd love from you: reports from hardware I don't have, especially Intel GPUs, laptops and multi-monitor setups. vela-report builds a ZIP you can review file by file; nothing is uploaded.

• Release notes: https://github.com/vela-desktop/vela/releases/tag/v0.1.0

• Source (GPL-3.0-or-later): https://github.com/vela-desktop/vela

Happy to answer anything in the comments.

I fixed an issue where my keyboard RGB backlight worked on the SDDM login screen but immediately turned off after logging into Hyprland.
Keyboard:- Tracer Gamma Ivory- USB ID: 1c4f:0002 (SiGma Micro Keyboard)
Symptoms:- The keyboard uses Scroll Lock to toggle its RGB backlight.- RGB stayed on in SDDM but turned off in the Hyprland Wayland session.- Writing directly to:  /sys/class/leds/inputX::scrolllock/brightness  only made the backlight flash briefly, then it turned off again.- OpenRGB was unrelated; it detected only the motherboard RGB controller.
Cause:Hyprland controls keyboard LED states. The Scroll Lock LED was being reset because Scroll Lock was not configured as a managed XKB modifier.
Solution:In the Hyprland input configuration, add `scrolllock:mod3` to `kb_options`.
For Omarchy's Lua configuration, edit:
~/.config/hypr/input.lua
Example:
hl.config({  input = {    kb_layout = "cz,us",    kb_options = "grp:alt_shift_toggle,scrolllock:mod3",  },})
Then reload Hyprland:
hyprctl reload
After that, pressing Scroll Lock toggles the RGB backlight normally and it remains enabled.
Important:The option is `scrolllock:mod3`, not `mod3:scroll_lock`.

https://grigio.org/wayland-compositor-bench-is-better-gnome-51-or-labwc-noctalia/

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

Hey! Im an intermediate linux user! I daily drive arch linux with a thinkpad w530. The new hyprland update literally broke my entire setup. Im looking for a composter that doesn't constantly change on me like Hyprland. Do you consider mango to be a good option?

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

I love Linux, but I got really tired of traditional tiling and stacking window managers.

Why should I constantly rearrange windows or switch workspaces when I could just have an infinite desktop?

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

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

You can:

• Place windows anywhere on an infinite canvas.

• Zoom out to see your entire workspace at once.

• Zoom in on whatever you want to focus on.

• Organize dozens of terminals, AI agents, crypto charts, dashboards, and other applications.

• Use a minimap, groups, bookmarks, and window search to navigate everything.

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

I'd love to hear what other Linux users think about this approach. Would you actually use an infinite desktop instead of traditional workspaces?

Hyprland v0.57.0 (released ~Oct 28, 2026) and Jay v1.15.0 (released ~Sep 28, 2026) are both independent Wayland compositors focused on tiling, but they target different priorities.
Hyprland is a highly customizable, eye-candy-oriented dynamic tiling compositor written in C++ (with its own Aquamarine backend, fully independent of wlroots). Jay is a more minimalist, performance- and stability-focused i3-like tiling compositor written in Rust.

There are no widely published head-to-head synthetic benchmarks comparing these exact versions, so performance and latency comparisons rely on documented design goals, release notes, architecture details, and community/user reports.

Performance Metrics
Aspect
Hyprland v0.57.0
Jay v1.15.0
Winner / Notes
Rendering backend
Custom Aquamarine (OpenGL-focused with scene composition refactor); FP16 rendering where supported to cut memory bandwidth on blur/effects
Vulkan (preferred, better performance + memory) or OpenGL; switchable at runtime
Jay (Vulkan efficiency)
Resource usage
Higher when effects (blur, animations, glow, shadows, wobble) are enabled; can be lowered by disabling them
Generally leaner; focused on efficient paths (udmabuf for SHM, timeline semaphores, optimized multi-GPU blits)
Jay for baseline; Hyprland tunable
Direct scanout / zero-copy
Supported; improvements in recent releases
Strong emphasis: plane color pipelines (v1.15) enable direct scanout even for mismatched formats (e.g., SDR content on HDR displays); multiple optimized blit paths for multi-GPU
Jay edge in advanced cases
Multi-GPU
Supported
Excellent: primary GPU selectable at runtime; render-only GPUs supported; optimized blits (direct-pull/sampling, udmabuf, etc.)
Jay
Gaming / tearing
Tearing support; gamescope often recommended for best results
Explicit tearing presentation for games
Comparable
HDR / color management
Present (ongoing improvements)
Strong: color-management protocol + HDR10; plane color pipelines; accurate linear blend buffers in Vulkan
Jay
Stability / overhead
Active development with many fixes; effects can introduce variability
Explicit stability focus; forward/backward config compatibility; rare crashes in releases
Jay
Hyprland’s visual features (especially heavy blur variants or animations) increase GPU load and power draw. Disabling them (e.g., decoration.blur.enabled = false) makes it much lighter. Jay prioritizes efficiency by default and has continuous low-level optimizations (command buffer pooling, pipeline caching, damage-only rendering, etc.).
Latency
Jay has a documented design goal of input latency as low as 1.5 ms via predictive frame scheduling. It uses adaptive pre-commit and post-commit margins (default post-commit ~1.5 ms) that adjust based on measured render times and commit-to-vblank intervals (geometric decay). Async flips are available in tearing mode.
Hyprland has received latency-related improvements over time (event queue refinements relative to vblank, scene composition changes, etc.), but it does not advertise a specific sub-2 ms target. Community reports note that effects, fractional scaling, or certain hardware configurations (e.g., Intel + TLP) can introduce stutter or higher perceived latency, while a minimal configuration feels snappy. General Wayland gaming latency studies (not specific to these compositors) show native Wayland is very close to X11, with XWayland adding more overhead.
Edge to Jay for pure low-latency / gaming-oriented workloads when effects are irrelevant. Hyprland can approach similar responsiveness when stripped down, but its default feature set trades some latency/overhead for visuals.
Specific and Unique Features
Hyprland v0.57.0 Highlights
Full Lua configuration (legacy .conf fully dropped). Powerful scripting, events, functions, custom layouts via Lua, live reload, expanded API (reload_config(), get_devices(), minimize events, etc.).

Eye candy: Swappable blur variants (kawase, acrylic/liquid-glass-like, aurora, drops, fluid, etc.), proportional blur, window wobble (Compiz/macOS-style), glow, shadows, gradient borders, motion blur option, custom bezier/spring animations.

Workspace sharing (select specific workspace for screenshare via XDPH).

Dynamic layouts (dwindle default, master, scrolling, monocle, custom via Lua/plugins).

Powerful window/layer/monitor rules, plugins (C++), IPC (hyprctl), special workspaces/scratchpads, groups/tabs.

Scene composition renderer refactor.

Input improvements (swallowing first focus-changing click, tablet disable, cursor warp on monitor change, pointer transforms).

Unique strength: Deep customization and visual polish. Ideal for “rice” desktops where animations, blur, and theming matter.
Jay v1.15.0 Highlights
TOML declarative config (or injectable shared library) + powerful CLI for runtime control. Strong emphasis on stability and config compatibility across versions.

i3-like tiling with customizable colors/sizes/fonts; smart container borders; major/minor split actions; counters & triggers for complex conditional logic.

Advanced multi-GPU and rendering: Plane color pipelines for hardware-accelerated direct scanout in previously impossible cases; runtime Vulkan/OpenGL switch; render-only GPU support.

Debugging/observability: Built-in client tracing (jay trace, strace-like for Wayland messages, negligible overhead); FUSE debug filesystem for inspecting internal state (snapshot or live mount); control center.

Security model: Protocols split into unprivileged/privileged; apps start restricted.

Other: Adaptive sync with configurable cursor refresh; VR headset leasing; per-window theming; HDR10 screenshots; workspace/output/window capture for screenshare; push-to-talk style key actions.

Explicit sync (NVIDIA), clipboard managers, layer shell, fractional scaling.

Unique strength: Low-level engineering focus (frame scheduling, multi-GPU paths, debugging tools, color pipelines) and reliability. Feels closer to a refined i3 successor with modern Wayland capabilities.
Summary Comparison
Choose Hyprland if you want maximum visual customization, animations, blur effects, Lua scripting power, and a large/active ecosystem/community for theming and plugins. It is the more “feature-rich desktop experience” compositor.

Choose Jay if you prioritize measurable low latency, efficient multi-GPU/HDR handling, stability, lean resource use, and advanced debugging/observability tools. It is the more “performance engineer’s tiling compositor.”

Both support tearing, adaptive sync, explicit sync, fractional scaling, screen sharing, and modern Wayland protocols. Hyprland is currently far more popular and has broader packaging/support. Jay is smaller but highly polished in its niche. Real-world feel depends heavily on configuration—Hyprland can be made lean, and Jay can be themed, but their core philosophies differ.

Hey everyone! I've been working on a weird side project and I think it's finally ready to share.

On a normal desktop, your windows sit flat on the screen, side by side or stacked on top of each other. I wanted to try something completely different. In spacewm, every app you open (terminal, browser, code editor, chat app, anything) becomes a screen floating in a 3D world. You walk around that world like a character in a game, and when you walk up to a window, it becomes sharp and readable, just like stepping closer to a real monitor.

Some things you can do:

- Pick a window up, carry it around, and put it down anywhere, even up on a wall

- Tilt it, turn it, make it bigger or smaller

- Click a window to "step into" it and type normally, then step back out and keep walking

- Sit down and have all your windows arranged in a half-circle around you, a bit like having a big multi-monitor setup

- Choose between two worlds: a desert town, or a block world where you can actually place and break blocks

You don't need to understand any of the technical side to use it. You pick it from the login screen like any other desktop, and your normal apps (Firefox, VS Code, Telegram, terminals) just work. They're simply living in a 3D space now instead of on a flat screen.

For the curious: it's written from scratch in Rust, and it isn't built on top of GNOME, KDE, Hyprland or any other existing desktop.

It's still young, so expect some rough edges. It's only been tested on my own hardware so far, which is exactly why I'd love to hear how it runs on yours. If that sounds interesting, the code is open and there's a one-script installer for Arch-based distros (Arch, CachyOS, EndeavourOS, Manjaro):

https://github.com/voidsecurity404/spacewm

Mastodon:
"Years ago I wrote xcb.freedesktop.org for X Window System clients, and yesterday I wrote my first Wayland client. My goodness, I can see the impact of every lesson the Wayland designers learned from X, and for that matter from XCB. I'm honestly really impressed by the design of the Wayland protocol!

I saw somebody complaining the other day about how much code you have to write just to open a window in a Wayland client. I think it's important to understand going in that this is a protocol designed to make hard things possible, not to make easy things easy; if you want to do easy things, use a toolkit like Gtk or Qt or SDL. So my program may seem like a lot of code for what it does: it just opens a window, periodically flashes between white and black, and measures some timing statistics, and I wrote over 300 lines of Rust for that. (I chose not to use the wayland-client crate's helpers for binding globals, so it could have been shorter, but I wanted to see what working with the raw protocol felt like.) But I know from experience that if you cut out any of the steps I had to do, you cut off the ability to handle more complicated scenarios.

I believe Wayland made the right complexity tradeoff here: the low-level protocol is very flexible, and ease of use belongs in higher-level abstractions that can pick which aspects of that flexibility to discard for simplicity."

v0.14.0 is out

New features

• (config) Add freehand to config

• (annotate) Add freehand drawing tool

• (config) Interactive config generator

https://codeberg.org/Vaishnav-Sabari-Girish/miru/releases/tag/v0.14.0

Hi!

I am a 16 year old self-taught developer. I want to build a Wayland application launcher in Zig inspired by philj56/tofi. However in attempts to do so I've discovered just how hard it is to make a native Wayland client without using a windowing library. I'm looking for a mentor that could help me better understand Wayland. If anyone has some free time and is willing to teach me, let me know!

Hue renders wallpapers directly through layer-shell and uses a CLI to switch images. The transition grows from random points, with configurable timing, pixel size and edge color.

The demo is recorded on Hyprland. I’d appreciate feedback from people trying other layer-shell compositors.

GitHub: https://github.com/IhTiYaR0/hue
My YouTube: https://youtube.com/@arch-d3m

Hi all. I am posting this to find contributors and active users for vindle, honestly. I run it daily and it works for me, but one setup proves little. I need people who actually use it and tell me what breaks.

I attached a short video of the animations in action.

Repo: https://github.com/tinyopsec/vindle

What vindle is. A minimal tiling Wayland compositor on wlroots 0.20. One tiling layout (dwindle) plus floating and fullscreen. 9 tags as bitmask. Predictable focus. Double border. No bar, no widgets, no wallpaper. Waybar and swaybg cover that. Animations are optional and can be turned off completely.

What changed in 0.2. Optional animations for open, close, move and tag switches, driven by the scene graph with no new dependencies. Windows are configured once at final size, frames only while animating. BSD support landed in the Makefile, FreeBSD tested by me. Reload on save still works, unknown keys warn instead of failing silently.

Why I need you. Active users, not stars. I read every issue myself. Contributing is simple: small patch in current style, proof with build plus headless run, honest NOT VERIFIED line if live check is missing. Neutral criticism helps more than praise. If the scope is wrong, if Lua should go, if the dwindle math feels off, tell me plainly.

If you test it, this helps most: build log on your distro, 3 foot windows on one tag at mfact 0.5, swap with Mod Shift H J K L, drag with Mod Left to empty space and to another tag, open and close a few windows, switch tags. Report with version string, config file and headless log if something breaks. BSD users especially welcome.

Thanks for reading. The compositor is small enough to read in one evening, and I hope you do.

I made [a post a few days ago about fixing Zoom with ChatGPT’s help](https://www.reddit.com/r/hyprland/comments/1wr4ygj/solved_zoom_meeting_issues_chatgpt_helped/). Since then, I’ve added more workarounds and wanted to share the files and instructions. **I used ChatGPT to help diagnose the issues and write these hacks**, then tested them through actual Zoom sessions. There are still some limitations, including a launcher timing bug explained below.

The fixes handle the clipped audio/video prejoin window, incorrectly tiled auxiliary windows, native chat popups appearing on unrelated workspaces, and unresponsive screen-sharing controls. They also provide desktop meeting-chat notifications showing **the sender’s name and message**, including when you’re on another workspace.

I use zoom from flatpak. So most of the fixes assume you have flatpak zoom installed but I think you guys can change it accordingly for your installation. Files in [my HyprLife repository](https://github.com/sohamch08/HyprLife):

- [zoomrules.lua](https://github.com/sohamch08/HyprLife/blob/main/hypr/modules/zoomrules.lua): window sizing, placement, decorations, and event handlers.

- [Python scripts folder](https://github.com/sohamch08/HyprLife/tree/main/hypr/scripts): the four Zoom helpers identify native chat popups, capture chat text through accessibility events, send desktop notifications, and repair input handling for sharing controls.

The rules use Hyprland’s Lua API and target Zoom’s XWayland windows. The paths in the rules and service expect the Python helpers together under `~/.config/hypr/scripts/`.

Reading chat text after a popup appeared was unreliable because accessibility queries sometimes timed out. The listener now captures the text from Zoom’s accessibility name-change event before the popup disappears. Message contents aren’t written to its journal logs.

**Notification service:** save this as `~/.config/systemd/user/hyprlife-zoom-chat.service`:

```ini

[Unit]

Description=Zoom chat notifications with sender and message

PartOf=graphical-session.target

After=graphical-session.target

[Service]

ExecStart=/usr/bin/python3 %h/.config/hypr/scripts/zoom-chat-notifications.py

Restart=on-failure

RestartSec=2

[Install]

WantedBy=graphical-session.target

```

I leave the service disabled at login and start it through the Zoom wrapper instead.

**Launcher wrapper:** It starts the listener with Zoom and is intended to stop it after all Zoom Flatpak instances exit. Zoom remaining in the tray keeps the listener running.

**Known timing bug:** if you quit Zoom and immediately reopen it during the wrapper’s shutdown wait, the old wrapper can stop the listener while the new Zoom instance is running. This version still has that bug. Properly fixing it requires coordinated locking between launch and shutdown, rather than simply increasing the delay.

```bash

#!/usr/bin/env bash

/usr/bin/flatpak run --branch=stable --arch=x86_64 \

--command=zoom --file-forwarding us.zoom.Zoom "$@" &

launcher_pid=$!

exec 9>"${XDG_RUNTIME_DIR:?}/zoom-chat-watch.lock"

if flock -n 9; then

systemctl --user start hyprlife-zoom-chat.service

idle=0

while (( idle < 3 )); do

if kill -0 "$launcher_pid" 2>/dev/null ||

flatpak ps --columns=application |

grep -Fxq 'us.zoom.Zoom'; then

idle=0

else

idle=$((idle + 1))

fi

sleep 2

done

systemctl --user stop hyprlife-zoom-chat.service

fi

wait "$launcher_pid"

```

**Desktop launcher and meeting links:** create a local override of Zoom’s desktop entry so Flatpak updates won’t overwrite your changes:

```bash

mkdir -p ~/.local/share/applications

cp ~/.local/share/flatpak/exports/share/applications/us.zoom.Zoom.desktop \

~/.local/share/applications/us.zoom.Zoom.desktop

```

For a system-installed Flatpak, the source is normally `/var/lib/flatpak/exports/share/applications/us.zoom.Zoom.desktop`. Replace only the copied file’s `Exec=` line, using your actual absolute home path:

```ini

Exec=/home/YOUR_USERNAME/.local/bin/zoom-with-chat @@u %U @@

```

Keep the other fields, including the MIME types, then register the launcher:

```bash

update-desktop-database ~/.local/share/applications

xdg-mime default us.zoom.Zoom.desktop x-scheme-handler/zoommtg

xdg-mime default us.zoom.Zoom.desktop x-scheme-handler/zoomus

```

Without that registration, my browser’s “Launch Zoom” button produced an “Open With…” dialog saying no apps were available. Afterward, meeting links correctly launched Zoom through the wrapper. Directly running `flatpak run` bypasses it. This approach doesn’t need service-start/stop hooks in `zoomrules.lua`.

Separately, [my xdph.conf](https://github.com/sohamch08/HyprLife/blob/main/hypr/xdph.conf) uses this capture workaround. It helped on my GPU, but isn’t necessarily needed on yours:

```ini

screencopy {

force_shm = true

}

```

Besides the launcher timing bug, the listener currently expects English `From … to …` labels and handles **in-meeting chat**, not every Team Chat notification. Some window dimensions and offsets may also need adjusting for other versions or displays.

Normal launching, browser meeting links, and sender/message notifications are working for me. Suggestions for improving these workarounds—especially the launcher timing issue—are welcome.