Repository navigation
Hyprland not support #638
Description
Activity
+1
+1
similar thing is happening with me, that the UI keeps disappearing when we move the mouse to the recordly UI, and its not usable, we cant click it even if we keep the mouse stable and the UI is visible. it disappears as soon as you click or move your mouse even a pixel.
Reacted by Abdulrhman Al-nahari and KristoferThe HUD becoming unusable on Hyprland comes from mouse pass-through being disabled on Linux. The recording control bar is a transparent, always-on-top overlay, so without pass-through every transparent pixel captures the cursor. Under focus-follows-mouse the bar flickers/disappears on hover, its buttons can't be clicked, and clicks on the windows behind it are blocked.
I opened #709 to fix this by enabling
setIgnoreMouseEvents(true, { forward: true })on Linux (same model Windows 11 uses) and keeping the overlay full-work-area + click-through while recording, since Wayland ignores programmatic window placement.If you want a working setup before that lands, on Hyprland you also need the overlay to float (a tiling compositor will otherwise tile the full-work-area window):
windowrule = float on, class:^(Recordly)$ windowrule = center on, class:^(Recordly)$ windowrule = border_size 0, class:^(Recordly)$Reacted by Abdulrhman Al-nahari and Anatolii TsyplenkovI reproduced this on CachyOS + Hyprland with Recordly 1.3.3.
The app opens, but under native Wayland/Ozone it can disappear/crash when hovering the UI or pressing Record. Launching Recordly with X11/Ozone fixes the issue:--ozone-platform=x11
I opened a PR that applies this workaround automatically for Hyprland sessions, so users do not need to manually edit their desktop launcher:
PR: #786
The change detects Hyprland on Linux and defaults Electron to X11/Ozone only there. It also respects explicit user overrides via --ozone-platform, OZONE_PLATFORM, or ELECTRON_OZONE_PLATFORM_HINT.Reacted by Bernardo Gomes and David BernardI can reproduce this on CachyOS + Hyprland 0.56.1 with Recordly 1.3.3.
I had a look at the Wayland protocol and noticed that the HUD changes its own window geometry whenever the mouse enters the overlay.
Initially the HUD is:
xdg_surface.set_window_geometry(0, 0, 860, 160)As soon as the pointer enters:
wl_pointer.enter(...)it becomes:
xdg_surface.set_window_geometry(0, 0, 860, 540) wl_surface.set_input_region(...) wl_surface.damage(0, 0, 860, 540) wl_surface.commit()When the pointer leaves:
wl_pointer.leave(...)it goes back to:
xdg_surface.set_window_geometry(0, 0, 860, 160)This happens every time I hover the HUD.
hyprctl clientsreports the window as:class: Recordly floating: true size: 860x160 xwayland: falseThe transparent area shown on screen matches the 860×540 surface.
As a workaround, launching Recordly with:
recordly --ozone-platform=x11
makes the HUD usable again.
Unfortunately this also means the cursor is already rendered into the recording, so Recordly can't apply cursor smoothing, click animations, motion effects, etc.
I'm attaching a screen recording to show the issue.
recording_20260805_220118.mp4
Reproduced on Omarchy (Hyprland 0.56.2) with the 1.3.3 AppImage and fixed in #863 together with Hyprland window rules for the transparent HUD (
pin,noblur,noshadow,nodim,opacity 1 1on class^[Rr]ecordly$), now documented in the README. The vanish-on-hover comes from the HUD window resizing on hover, which Hyprland re-centres; the bar then lands ~190px away from the pointer or off-screen.
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):