AIMP Forum
AIMP for PC => Ошибки и замечания / Bugs => Topic started by: tacticaltoad on August 03, 2026, 00:04:44
-
OS: Fedora Linux 44 (Workstation Edition)
DE: Niri WM (26.04) on Wayland
When running on the Niri WM, the AIMP window is presented via xwayland-satellite, which is the tool that Niri uses to bridge the Wayland <-> X11 conversion for X11 applications. When running like this, I have noticed that UI elements in AIMP skinned windows (like the main player, music library, visualization window, etc.) do not properly react to hover interactions: placing the cursor above a button does not change the button state or it only does so some times, and the cursor becomes "stuck" in that state until it leaves the AIMP window or you click somewhere. This appears to affect only hover and similar actions like resizing sections of the music library by dragging the borders, though. Clicking on the buttons works without issue and other items like the waveform animation under the album art on the default Charm skin play as normal and don't appear to have any noticeable lag or issue.
I have looked into the Niri / xwayland-satellite side of things and checked their docs and GitHub issues for any clues on what could cause this behavior. My current theory is that this is related to window positioning. By default, xwayland-satellite tells top-level X11 windows that they are positioned at 0,0 and that they should use the full space available to them, which is usually the actual Wayland window inside which the "fake" X11 environment exists. I found this relevant because when I tested running AIMP inside other nested sessions / X11 compositors like Xephyr, labwc and base Xwayland, I was reliably able to reproduce this behavior whenever I aligned the top-left corner of the AIMP window with the screen origin and only in that case. As soon as the AIMP window was offset even one pixel either vertically or horizontally, the button hover started working again.
-
An additional thing that I forgot to add: the top-left corner of the AIMP window I am referring to is not where the UI starts, but rather the transparent padding that the main window seems to have all around it. On older xwayland-satellite versions that didn't support proper alpha composing this section looked like a black border around the AIMP window, but the latest version fixed that and now it is properly transparent, which makes the AIMP window look like it has an extra "padding" from the edge of the container Wayland window and its focus ring (window active indicator border).
-
Niri WM is not supported by the app. App can work on Gnome, KDE, Cinnamon, Mate or XFCE.
-
Ah, such a shame to hear that. Is there any specific technical reason / limitation why that is the case? I think I have seen some comments elsewhere stating that this was due to Niri not supporting alpha composition, but this seems to have been an issue with xwayland-satellite and not Niri itself. The most recent version no longer gives the "alpha composing is not available" warning when running AIMP from the command line.
For me the app has been working great (including global hotkeys and system integration) with the exception of this one thing, which appears to be solvable, I think.
If this cannot be solved on the AIMP side, is there any insight you could share on why you think this issue happens so that I could look for a workaround? I would really appreciate that. As I mentioned on my original post, the weird behavior only happens when the AIMP window is placed with its topmost left corner aligned with the screen origin, and moving it even slightly from that position makes it fix itself. I tried this running it under a nested X server, so that for AIMP it looks like it is on a regular desktop environment, and this was the case every time.
Long time AIMP user under Windows, by the way. I was very happy to see it finally go Linux-native. Thanks for your hard work on this amazing piece of software!
-
Most window commands work the same way, but some either don’t work or work differently from what’s expected. Unfortunately, there are a lot of WMs for Linux, and they’re all very different; we simply can’t support all of them physically. Therefore, we’ve now focused on the most common variants to make app stable and release it.