Skip to content
Waxed Display Server
MIT-0 Licensed

Waxed Display Server

A plugin-based display server where every plugin can be its own desktop environment. Waxed handles VSync, VRR, multi-monitor, and rendering - you focus on building a beautiful, unique user experience that stands out.

Support Development

I'm building this as a hobby project, using AI to do the heavy lifting. That combination actually works surprisingly well. But I still need to steer it, debug it, and find time between whatever pays the bills. Donations buy me more hours to work on Waxed and LEF instead of client work.

Yearly Goal 4.2%

Build for the future. Game-like tech.

Vulkan-powered rendering with modern C++26. Create stunning desktop environments with the same technology used in games - no legacy holding you back.

View all features and status
Done

Dev Keyboard Shortcuts

CTRL+ALT+DELETE kills Waxed, CTRL+ALT+BACKSPACE restarts it

Done

Hardware Cursor

Mouse cursor rendered on a hardware plane

Done

DRM Planes

Hardware-accelerated compositing using DRM/KMS planes

Done

Modern C++26

Clean codebase using RAII and modern patterns

Done

Per-Display Refresh Rates

Each monitor runs at its optimal refresh rate independently

Done

No D-Bus, No SystemD

Minimal dependencies, only SeatD required

Done

Shader Service

Centralized shader management with hot reload

Done

Triple Buffering

Smooth rendering with triple buffering managed by Waxed

Done

VSync

Perfect frame synchronization without tearing

Done

Variable Refresh Rate

Full VRR support built-in

Done

Vulkan 1.3+

Requires Vulkan 1.3, works on Raspberry Pi 5

Done

waxedctl

CLI tool exposing all API/IPC features

In Progress

Monitor Configuration

Built-in utilities for display configuration

In Progress

Core API/IPC

Standardized API for third-party toolkits

In Progress

Mouse Gestures

Gesture detection built into core

In Progress

Multi-Monitor

Seamless multi-display setups

In Progress

Texture Server

Off-main-thread texture loading for images and video

Planning

Hardware Video Path

Full hardware path for video playback with zero format conversion

Planning

Permission Model

Security baked into core with user-facing prompts

Planning

Virtual Desktops

Core-level virtual desktop support

Plugin-first plugins

A desktop environment is just a plugin. The core handles all the hard stuff - your plugin inherits everything and builds the UX.

Waxed Core

All infrastructure included

Rendering, input, security, IPC, hardware abstraction - all handled. Your plugin gets it all without writing a single line.

Your Plugin

Inherits everything

Focus on window management, UI, theming, and user experience. The hard stuff is already done.

Your Plugin Handles

Window Management

Tiling, floating, tabbed - whatever paradigm fits your vision.

UI & Theming

Visual style, decorations, colors - your aesthetic, your way.

User Interaction

Gestures, keybinds, workspaces - design the UX your users will love.

Special Features

Effects, animations, integrations - what makes yours unique.

Why Waxed?

A different approach to display server development - built for developers who want to create, not replicate.

End the Fragmentation

Wayland, the supposed successor to X11, promotes fragmentation - every compositor must implement protocols themselves. Sharing code is difficult despite wlroots. Waxed flips this mentality: a shared core handles the problematic parts internally, plugins extend and build on top. A plugin can even override core features if needed. This creates an ecosystem where everyone benefits from shared improvements.

Simplicity First

Writing compositors is hard as-is. So why not make it simple? It makes no sense for every plugin to implement triple buffering, VSync, or VRR. Waxed handles all of this internally so plugins can focus on what matters: building a unique, beautiful desktop experience that stands out from the crowd.

Rapid Development Cycles

Quick development cycles mean faster progress. During these early stages, we aim for snapshot releases every 2 weeks. This allows for rapid iteration, quick feedback loops, and steady progress toward stable releases. You won't wait months for features to land.

Feature-Friendly Philosophy

We're very open to new feature requests in the core, as long as they don't break other features or complicate future development. You won't find political reasons here to ban features. The only exception: Wayland-specific concepts are permanently banned from Waxed - we're building something different.

Free Future Upgrades

Future improvements are free additions to plugins. Features like color management and HDR - not currently in development - would become instantly available to all plugins as soon as the core supports them. Your plugin automatically gets better over time without any extra work.

AI-Native Development

We embrace AI to the fullest. We don't care if contributions come from humans, vibe coding, or bots - if the feature is good and doesn't break anything, it will likely be accepted. Much of Waxed is built using GLM 4.6, 4.7, and now 5 models. Without AI, this project would be impossible. We recommend being a developer by trade so you can effectively steer AI in the direction you want.

MIT-0 Licensed

Waxed and LEF are MIT-0 licensed, meaning no attribution required. Feel free to use this creation however you please. BSD and LGPL were options too, but we opted for as few restrictions as possible. This means it's free enough for anyone, even commercial entities, to take it and run with it. We'd consider that a compliment.

No Commercial Intent

The site might be .com, but that's only because it was the cheapest option. Waxed and LEF will never be commercial by our hands. There will never be a pricing model. The most there will ever be is a non-obtrusive donation button in LEF, but even that is unlikely. The site will have a donation option though.

No SystemD Ecosystem

Waxed and LEF won't use or link to anything from the SystemD ecosystem. We're not against it, but it proved hard to use during development - Logind was already impossible - so we just didn't try further. We do require SeatD for seat management, which is minimal and works well.