I like my Breeze-hacked cursor but I think it’s time to find a native Wayland replacement.

I have some problems with X11 cursors and that’s quite normal with Wayland obviously. For example, my cursor can become invisible if my screen sleeps. Additional controllers that control mouse cursor don’t control X11 cursor, however they still work, I just don’t know where the cursor is unless it highlights something. Things like this.

It’s becoming kinda inconvenient so I’m asking for a replacement. Currently I don’t really care how it looks.

I’m on River by the way.

  • muhyb@programming.devOP
    2·
    2 months ago

    I see. So nothing really changed? I was starting to think that it might be related to permissions in Wayland, apparently not.

    That’s either a compositor or driver bug, please report it (as I’ve never seen that on Plasma, to your compositor first).

    Hmm, in that case it could be a Hyprland issue. I would say wlroots but they stopped using wlroots and I switched to River recently. Haven’t happened on River yet but it’s been only a week so I cannot say for now.

    That’s because it moves the X11 pointer but not the real one. A cursor theme can’t change that.

    The real one? It was fine on Xorg though. I tried to put my user into input group, thinking could be related to a permission issue but it didn’t change anything.

    • Zamundaaa@discuss.tchncs.deEnglish
      4·
      2 months ago

      The real one? It was fine on Xorg though

      When an app (in your case, Steam) uses X11 APIs to move the cursor, that of course works on Xorg, but Xwayland merely emulates it - so it moves the X11 pointer for X11 apps, but not the pointer from the Wayland compositor.

      Some compositors allow Xwayland to request moving the real pointer instead of doing emulation, but River apparently doesn’t.

      • muhyb@programming.devOP
        2·
        2 months ago

        So even if there was a native Wayland cursor, that wouldn’t fix it too unless everything is native Wayland?

        Some compositors allow Xwayland to request moving the real pointer instead of doing emulation, but River apparently doesn’t.

        Then this shouldn’t happen with native Wayland apps I assume. I guess some problems could occur since it’s a transition layer. Though I don’t know the working mechanism of Xwayland. I’m kinda confused. So this is a pointer issue but not input issue?