You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Linux/Hyprland: HUD overlay unavailable on pure Wayland (no layer-shell) #756
Arch Linux, Hyprland (pure Wayland, no XWayland), xdg-desktop-portal-hyprland
What happened?
When running Hex on Hyprland under pure Wayland (where XWayland is disabled/not running), the recording HUD pill never appears on screen during dictation. Audio capture and transcription still work in the background, but there is no visual indicator or feedback that Hex is listening.
In the systemd user journal, Hex logs:
WARN hex::linux_rune_hud: HUD unavailable: compositor has no layer-shell and XWayland is not running; dictation still works
Expected behavior: The HUD indicator should display on screen during dictation across Wayland compositors supporting wlr-layer-shell.
Steps to reproduce
Launch Hex on Hyprland without XWayland (XDG_SESSION_TYPE=wayland).
Trigger dictation via hotkey or hex dictation start / hex dictation toggle.
Observe that no HUD overlay appears on screen.
Additional context
Log excerpt from hex.service:
WARN hex::linux_rune_hud: HUD unavailable: compositor has no layer-shell and XWayland is not running; dictation still works
Suggestion:
Implement native zwlr_layer_shell_v1 protocol support for the Rune HUD surface so the recording indicator can render natively on modern Wayland compositors (Hyprland, Sway, River, etc.).
rune already draws the hud as a layer-shell surface on wayland, so hyprland should get it without xwayland. limitation() in src/linux/rune_hud.rs prints the same warning when hex doesn't see zwlr_layer_shell_v1 and when rune reports the overlay unavailable, so the log doesn't say which happened. since hyprland offers layer-shell, rune failing to open the overlay is the likelier cause, possibly because the systemd-started service has no usable wayland display (no WAYLAND_DISPLAY, or a session.env that's missing or stale), but i can't confirm that from hex's code alone.
the warning text is the same for both cases, so the journal line alone doesn't point to the cause
rune is a pinned git dependency, so if its overlay is what refuses, the fix belongs in rune, not in a workaround in hex
nobody has tested hex on hyprland without xwayland yet, so this could also be a gap in rune's layer-shell path on hyprland
does the hex settings window open when hex runs as the service, and does the hud show if you start hex app directly from a hyprland terminal instead of through systemd?
would be useful to see the service's journal lines around the warning, plus your hyprland version
the hud already uses layer-shell. what was most likely happening is hex.service got started by systemd without your hyprland session's env, so it had no WAYLAND_DISPLAY at all, and the warning said "no layer-shell" for that case too
fixed in #758 (next dev build): the service now finds your wayland socket itself when it starts without one, and the log says which case it actually hit (no display, no layer-shell, or the overlay failing with its error). tested on a headless sway with xwayland off, the hud shows. haven't run it on hyprland itself
you can also add this to your hyprland config so systemd services get your session env in general:
Activity
thdxr commentedon Nov 1, 2026
rune already draws the hud as a layer-shell surface on wayland, so hyprland should get it without xwayland.
limitation()insrc/linux/rune_hud.rsprints the same warning when hex doesn't seezwlr_layer_shell_v1and when rune reports the overlay unavailable, so the log doesn't say which happened. since hyprland offers layer-shell, rune failing to open the overlay is the likelier cause, possibly because the systemd-started service has no usable wayland display (noWAYLAND_DISPLAY, or a session.env that's missing or stale), but i can't confirm that from hex's code alone.the warning text is the same for both cases, so the journal line alone doesn't point to the cause
rune is a pinned git dependency, so if its overlay is what refuses, the fix belongs in rune, not in a workaround in hex
nobody has tested hex on hyprland without xwayland yet, so this could also be a gap in rune's layer-shell path on hyprland
does the hex settings window open when hex runs as the service, and does the hud show if you start
hex appdirectly from a hyprland terminal instead of through systemd?would be useful to see the service's journal lines around the warning, plus your hyprland version
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
Linux HUD: say why it can't show; the service finds the session's Way…
thdxr commentedon Nov 1, 2026
the hud already uses layer-shell. what was most likely happening is hex.service got started by systemd without your hyprland session's env, so it had no
WAYLAND_DISPLAYat all, and the warning said "no layer-shell" for that case toofixed in #758 (next dev build): the service now finds your wayland socket itself when it starts without one, and the log says which case it actually hit (no display, no layer-shell, or the overlay failing with its error). tested on a headless sway with xwayland off, the hud shows. haven't run it on hyprland itself
you can also add this to your hyprland config so systemd services get your session env in general:
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊