After dedicating more time than initially planned to Unreal Engine’s Linux integration and learning more about how both Unreal and Wayland work, I’ve concluded that extending the existing LinuxApplication for Wayland support is no longer the right approach.
The current codebase is fundamentally designed with X11 in mind. While it’s technically possible to add Wayland functionality, doing so requires constantly working around assumptions that don’t apply to Wayland—such as global coordinates, client-controlled window placement, and cursor warping. Each adjustment introduces more conditionals and edge cases, complicating the code further. And when one thing got fixed, I’d find out later that it only hid the problem or made others worse.
So, instead of layering fixes onto an incompatible foundation, I’m stepping back to pursue a cleaner, more sustainable solution.
Rather than modifying LinuxApplication, I plan to treat Wayland as its own distinct platform by introducing a separate application layer—tentatively named FWaylandApplication. This approach leaves the X11 implementation untouched and prevents the existing Linux code from becoming cluttered with special cases.
This isn’t a radical departure; Unreal Engine already follows this pattern for other platforms. The goal is to give Wayland the dedicated attention it deserves, rather than treating it as an extension of X11.
Attempting to replicate X11-style behavior on top of Wayland creates unnecessary friction. A dedicated platform layer allows Wayland to function as intended, without forcing it into an incompatible mold.
A properly implemented Wayland path addresses a number of long-standing issues in a way that is both cleaner and easier to maintain than the current approach. Fullscreen behavior can finally align with compositor expectations instead of relying on exclusive or borderless hacks, which removes a whole class of focus and mode-switching problems. Input handling becomes more flexible and robust, allowing packaged games to release input cleanly without forcing players to Alt-Tab out of the application just to interact with something else on a second monitor — a workaround that often leaves input grabs in a broken or inconsistent state on Wayland. When input is released, the cursor can move naturally outside the window without warping or confinement tricks, making multi-monitor use feel intentional rather than accidental. Multi-monitor support itself becomes simpler and more predictable, since the compositor manages output placement and fullscreen surfaces instead of the engine trying to infer global coordinates. UI elements such as tooltips, popups, and notifications can be implemented using proper parent-child relationships, which avoids positioning glitches and focus issues. HiDPI and fractional scaling can be handled correctly through compositor-provided scale factors rather than guesswork, and HDR can be supported where the compositor exposes the necessary protocols. Because the Unreal Editor and packaged builds share the same platform layer, these improvements apply consistently across both, rather than existing only in editor-specific code paths or one-off fixes.
This shift will likely require refinements to how Slate manages windows and popups. Certain behaviors that were implicit under X11 may need to become explicit and platform-aware. The aim is to enhance Slate itself rather than creating a hard fork, though some breaking changes may be necessary along the way.
SDL will remain useful for certain tasks, such as input handling and possibly notifications along with other things that each distribution handles differently rather than it being just a wayland thing. However, relying on it for windowing and fullscreen management under Wayland has limitations. Native Wayland support provides greater control and avoids dependencies on abstraction layers that may lag behind.
The immediate scope of this work is to get the Unreal Editor running cleanly and predictably on Wayland without relying on compatibility layers or workarounds. That starts with being able to launch the editor with correct input handling and rendering from the outset, followed by establishing proper windowing, focus, and fullscreen behavior that respects the compositor instead of fighting it. From there, the goal is to support multi-window editor workflows in a way that feels natural under Wayland, including detached panels and secondary windows on multi-monitor setups. Because the editor and packaged games share the same underlying platform layer, any fixes or improvements made here should automatically carry over to packaged builds, ensuring games benefit from the same behavior without requiring separate, game-specific logic.
Longer term, this foundation could enable Unreal Engine to be used more effectively for non-gaming applications on Wayland, though that remains a future consideration.
This effort is less about adding new features and more about building the right foundation. Continuing on the previous path would only increase complexity without addressing core incompatibilities. A dedicated Wayland platform layer offers a clearer, more sustainable path forward.
I’ll share further updates as the work progresses.
