Unity Editor keyboard input broken under Niri — xwayland-satellite architectural incompatibility

[Jurgencotting]

⚠️ Disclaimer: I'm sorry in advance — this text was written with the help of AI
(Claude) because I'm not very experienced with programming, I don't fully understand
all the technical details involved, and my English is quite poor. But I love Niri and
I really wish it could work well with Unity, so I wanted to report this properly as
best I could. Please bear with me! 🙏

---

Summary

Unity Editor (and the Unity Hub launcher) have persistent keyboard input issues when
running under Niri via xwayland-satellite. After extensive testing and investigation,
the root cause appears to be an architectural incompatibility between xwayland-satellite's
external XWayland approach and how Unity handles window focus and absolute screen
coordinates.

---

Environment

• Compositor: Niri (latest stable)
• XWayland bridge: xwayland-satellite
• GPU: NVIDIA GTX 1650 Mobile (PRIME offload, drivers 595.58.03)
• OS: CachyOS (Arch-based)
• Unity version: Unity Editor (2022.x / 6000.x)

---

Symptoms

The following issues were consistently reproducible:

1. "Add Component" search box — typing anything in this field produces no input.
   The popup opens but the keyboard is completely unresponsive.

2. Asset renaming in the Project panel — double-clicking to rename an asset shows
   the text field but keyboard input does not register.

3. Unity Hub — occasional focus and input issues in the launcher itself.

These issues do not occur on:

• Native X11 sessions (TTY-based startx)
• Compositors with integrated wlroots XWayland (Hyprland, MangoWM/sway-based)

---

Investigation & Testing

xwayland-satellite PR #397 (WM_TAKE_FOCUS fix)

I tested xwayland-satellite PR #397,
which addresses popup focus logic for WM_TAKE_FOCUS windows.

Result of A/B testing:

Behavior	Without PR #397	With PR #397
"Add Component" typing	❌ Broken	✅ Fixed
Unity asset renaming	❌ Broken	❌ Still broken
Steam client hover/interaction	✅ Working	❌ Regressed

The PR fixes one input path but introduces regressions in other XWayland applications
(specifically Steam). This suggests the WM_TAKE_FOCUS handling is genuinely complex
and a single fix cannot satisfy all applications simultaneously.

Workarounds attempted

Workaround	Result
TTY-based X11 session (startx)	✅ Unity works fully — confirms it's a Wayland/XWayland issue
cage nested compositor (XWayland inside Wayland)	❌ Did not resolve keyboard input
Running Unity with DISPLAY pointed to satellite	❌ Same issue
Various _NET_WM and focus hint overrides	❌ No effect

All Wayland-based workarounds were eventually reverted.

---

Root Cause Analysis

The core problem seems to be how Unity uses absolute screen coordinates and focus
protocols that conflict with xwayland-satellite's external/satellite architecture.

Niri delegates XWayland support to xwayland-satellite as an external process,
which means it does not have the same level of integration with the compositor's
internal window tree and focus management that native wlroots-based compositors
(like Hyprland or MangoWM) have.

Unity appears to rely on:

• WM_TAKE_FOCUS (ICCCM protocol) for certain popup/modal inputs
• Absolute screen coordinates for input event targeting
• Assumptions about focus being retained when a child popup opens

xwayland-satellite's external model seems unable to correctly relay these focus
events in all cases, particularly when Unity opens transient windows (like the
"Add Component" search or the rename field) that expect to inherit keyboard focus
from the parent editor window.

---

Comparison with other Wayland compositors

Compositor	XWayland model	Unity status
Niri + xwayland-satellite	External/satellite	❌ Broken
Hyprland	Integrated (wlroots)	✅ Works
MangoWM (wlroots-based)	Integrated (wlroots)	✅ Works
Sway	Integrated (wlroots)	✅ Works

This strongly suggests the issue is specific to the satellite architecture rather
than Niri itself or the user's hardware/drivers.

---

Request / Question

Is there any known path toward fixing this in xwayland-satellite, or would this
require changes on Niri's side? Is there any plan to support a more integrated
XWayland model in the future, or is the satellite approach a fundamental design
decision for Niri?

I'm happy to provide any additional logs, WAYLAND_DEBUG output, or test specific
patches if that would help. I just want Niri and Unity to get along — it's my
favorite compositor and I'd love to not have to switch! 💙

Thank you for your time and for the amazing work on Niri.

[bczhc]

Maybe worth reporting to xwayland-satellite then, I think. niri can do nothing.

I've done a quick search and there are related issues:

Supreeeme/xwayland-satellite#278
Supreeeme/xwayland-satellite#286

Is there any plan to support a more integrated
XWayland model in the future

Hm sadly no. From the wiki

We're using xwayland-satellite rather than Xwayland directly because X11 is very cursed. xwayland-satellite takes on the bulk of the work dealing with the X11 peculiarities from us, giving niri normal Wayland windows to manage.