KDE Plasma Wayland: Mouse cursor is not visible

[Firlaev-Hans]

Describe the Bug

Like the title says. Using my Arch Linux PC with Plasma on Wayland as the Sunshine host, I can't see the mouse cursor in moonlight. I see the cursor move on the Sunshine PC's screen when I move the mouse on the Moonlight client device, but in Moonlight it is not visible.

Expected Behavior

The mouse cursor should be visible on the client

Additional Context

No response

Sunshine Host Operating System and Version

Arch Linux

Architecture

x86_64

Sunshine Version

0.13.0

GPU Type

AMD

GPU Model

Radeon RX 580

GPU Driver/Mesa Version

21.3.7

Capture Method (Linux Only)

PipeWire / VAAPI/ Wayland (KMS)

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove the stale label or comment, otherwise this will be closed in 5 days.

[Firlaev-Hans]

This issue is stale because it has been open for 30 days with no activity. Remove the stale label or comment, otherwise this will be closed in 5 days.

Well, it's still an issue currently.

[v44r]

Same here on sway (Arch), so probably wayland related, not just KDE plasma. Everything works great except for this issue. The mouse works, since I can interact with buttons or links, but the cursor is invisible.

[nisegami]

I found this issue opened and subsequently closed on the Pipewire repo. The issue was the cursor not being present when screen-sharing in Firefox. Apparently, Firefox (actually webrtc?) was not implementing some sort of cursor metadata that Pipewire uses to determine if it should send the cursor. Could this be related to this issue? As already mentioned, it seems to be compositor independent, so the issue resulting from Pipewire interactions sounds reasonable to me.

In the meanwhile, using Gamescope seems to display the cursor. I've only tested one game, but I will be testing more soon and reporting back.

[muskwasis]

Works in nightly

[voidanix]

Strange that it works for you, still cannot see the cursor here on nightly with GNOME 40.4/Wayland

[nisegami]

Strange that it works for you, still cannot see the cursor here on nightly with GNOME 40.4/Wayland

Same here, cursor not visible unless using GameScope on the latest nightly with KDE/Wayland

[muskwasis]

Oh sorry I was replying to @v44r. @nisegami How are you running gamescope? I cannot get it to start using it in embedded mode. I'll give GNOME 40.4/Wayland a test as well.

[v44r]

Yeah, I don't know what fixed it, but now I can see the mouse cursor, no problem (using sunshine from AUR, so still 0.13.0... maybe something in sway or wlroots fixed it?).

[lbfalvy]

I just got this issue, after updating to Plasma 5.25. I've been running Plasma with Wayland for a month or so but it just didn't occur until the update. I can sometimes see the cursor, it spontaneously appears when it's supposed to change state (but the same states aren't always visible).

[JustPlainGarak]

I was just able to install the latest rpm release on Fedora 36 and can also confirm that my mouse cursor is not visible in Moonlight while using KDE Plasma on Wayland on the host.

[lbfalvy]

I commented here in err, my mouse cursor was missing on a plain Wayland host without any streaming and I don't know what Sunshine is, but setting KWIN_FORCE_SW_CURSOR=1 in ~/.config/environment.d/ fixed it and from what I gather it's supposed to be a wildcard solution for a variety of problems around missing cursors. Note that .profile or other scripts aren't executed by Wayland so you can't set the variable there, and since KWin needs to read it Systemd is probably the only place it'll work. Apparently software cursors aren't very good for performance, so this isn't a long-term solution.

[Pipyakas]

I commented here in err, my mouse cursor was missing on a plain Wayland host without any streaming and I don't know what Sunshine is, but setting KWIN_FORCE_SW_CURSOR=1 in ~/.config/environment.d/ fixed it and from what I gather it's supposed to be a wildcard solution for a variety of problems around missing cursors. Note that .profile or other scripts aren't executed by Wayland so you can't set the variable there, and since KWin needs to read it Systemd is probably the only place it'll work. Apparently software cursors aren't very good for performance, so this isn't a long-term solution.

is there any equivalent solution for GNOME?

[JustPlainGarak]

I found this issue opened and subsequently closed on the Pipewire repo. The issue was the cursor not being present when screen-sharing in Firefox. Apparently, Firefox (actually webrtc?) was not implementing some sort of cursor metadata that Pipewire uses to determine if it should send the cursor. Could this be related to this issue? As already mentioned, it seems to be compositor independent, so the issue resulting from Pipewire interactions sounds reasonable to me.

In the meanwhile, using Gamescope seems to display the cursor. I've only tested one game, but I will be testing more soon and reporting back.

I'm using @lbfalvy workaround posted above, but I'm curious what you're doing with gamescope to work around the issue as well, as I'm not 100% sure what implications forcing a software mouse cursor has on my general computing experience.

[nisegami]

I'm using @lbfalvy workaround posted above, but I'm curious what you're doing with gamescope to work around the issue as well, as I'm not 100% sure what implications forcing a software mouse cursor has on my general computing experience.

I'm actually also using the software cursor workaround. I haven't noticed any issues with it yet personally.

When I said that Gamescope displayed the cursor, I meant in actual games. So if I setup Steam to launch a cursor based game using Gamescope and then launched the game while streaming via Sunshine, the cursor would be visible. However, shortly after replying I realized that Gamescope doesn't play nice with the Steam controller, making it not really a viable solution for me.

[lbfalvy]

To all using the software cursor workaround, this got fixed for me with a recent update so you may want to try removing it. I can attest that without the hack my desktop is much faster, I think it's got to do with the fact that layers can be drawn in parallel.

[JustPlainGarak]

Unfortunately the issue is not yet fixed for me, will have to keep using the software cursor workaround.

[kode54]

No software cursor workaround available for Gnome.

[FormBurden]

This does help a lot. Another reference is here: Reddit Post. This really needs to be fixed or something than just a workaround. Because I use this when using Wayland since X11 doesn't have this issue. Not only that, but Streaming a game like Minecraft to my Steam Deck, the cursor is shown due to this workaround, but if you use the controller addon for Minecraft and move your joysticks around that would use the mouse. The mouse is invisible as well (joysticks mimicking the mouse for the addon), this workaround does nothing. But if you have the trackpads be used as mouse (the mouse keybind, not joysticks), this issue is not there. So obviously there's a lot of issues here. Hopefully gets fixed soon.

X11 does not have these inconsistencies, such as the Minecraft issue. But I enjoy Wayland much more than X11.

Anyway, a few tidbits and such.

[BA8F0D39]

Moonlight Sway Wayland on the client Sunshine 1.60 on the windows host

When I plug a mouse into the host there is a cursor When I remove the mouse from the host there is no cursor

Nvidia gamestream works perfectly with Moonlight

[kode54]

Windows doesn't display a cursor if there's no mouse attached. The workaround for this is to enable MouseKeys.

[jwp2987]

For what it's worth, I just had the mouse disappear on a Ubuntu 22.04 system. Oddly enough the T2 instance I have running on a Mac Pro didn't have the problem, noticed that it was using a 6.x kernel. I manged to resolve it by upgrading the amdgpu driver and building sunshine from source. Trying to add a mouse to the headless system didn't resolve my problem, it the bug was also present in both KDE and Gnome.

[akhil-rana]

For Gnome, arch, wayland, setting

MUTTER_DEBUG_DISABLE_HW_CURSORS=1

in /etc/environment seems to be working for me

But weirdly I have an extra cursor (not moving) on my screen in some windows.

[reza-naq]

@lbfalvy In which file under ~/.config/environment.d/ do you suggest to write the line/ I added the variable in my .zshrc and it didn't help.

[lbfalvy]

@lbfalvy In which file under ~/.config/environment.d/ do you suggest to write the line/ I added the variable in my .zshrc and it didn't help.

tl;dr: ~/environment.d/50-kwin-sw-cursor.conf will work

~/environment.d/ is the per-user systemd environment. Any non-hidden filename should do, the convention for files in **.d/ configuration directories is to begin with two digits and a dash, as the order of execution can be specified by modifying the digits. .zshrc doesn't work because the variable should be available to kwin. Generally speaking, you can only use zshrc to customize your terminal environment, although I have successfully used bashrc to delay the launch of daemons I only need in situations where I would open the terminal. You couldn't put the variable in any other script file either, as Wayland doesn't have a startup script. That's why we use systemd to set envvars for the whole session.

Edit: this is inaccurate, see my next comment

[reza-naq]

@lbfalvy The first time I created a file in ~/.config/enviroment.d/ it was a hidden file called .profile. After your last post I created a new one following the ordering scheme you described. Ir didn(t work either. I posted few questions here & there, KDE & freedesktop forums. No response from the 1st one and the latter were quick to close my issue. Thanks a lot for you detailed response.

[tjssoldier]

@akhil-rana Thanks! It works but the cursor becomes invisible when i play a video in fullscreeen.

I think this topic need to be renamed since this seems to be a general problem in Wayland.

[lbfalvy]

@reza-naq Actually my bad, the file needs to match ~/.config/environment.d/*.conf as described in man environment.d, the digit prefix is a convention. Also make sure that you don't prefix your envvar declarations with export; these aren't script files, they're parsed by systemd. The manpage should answer most of your questions.

If you want to determine whether your assignment is working, try relogging and printing the variable with echo $KWIN_FORCE_SW_CURSOR. If the variable isn't being set, the problem relates to systemd and environment.d in particular. If the variable is being set but doesn't fix the cursor issue, the problem relates to KDE and kwin.

@tjssoldier this topic needs to be moved to a different repo or a different forum even, but I've been referencing it for months so I'd rather the link didn't die. If the Sunshine team prefers it could be closed and appendable.

[reza-naq]

@lbfalvy I'd named it actually almost as you say in your post: 10-kwin-force-sw-cursor=1. And I just checked out. The file is picked up by Wayland because echo show the value correctly. I think this regards Wayland team. I've already posted something there with no response so far. I'm using Plasma/X11 for the moment. As I check the packages list each time I update the system I'll try it again if see a Wayland upgrade. The most important is to let them now that this problem is there, at least for a configuration like mine.

Actually I say Wayland but it can be, as you say, KWIN, KDE or some driver. My knowledge comes short of saying which one.

[OlegAckbar]

Have the same issue.

[andrewKode]

Actually I say Wayland but it can be, as you say, KWIN, KDE or some driver. My knowledge comes short of saying which one.

KDE, KWIN is definetly not the issue. I cannot use my mouse nor my keyboard and I've tried two hosts so far. One with Fedora 37 and Gnome and other Ubuntu 20.04 with Gnome. None are working. One is using Wayland and one is using X11. So what can it be if everything is not the issue?

[Smoukus]

I have the same issue as well. I am on EndeavourOS (arch basically) - downloaded sunshine from AUR. I am on KDE Wayland, kernel 6.2.rc8, mesa-git, AMD GPU & CPU.

Host is this PC, and Client is Nvidia Shield.

Mouse cursor is invisible on the client. It works just fine, it's just not visible.

[greyltc]

This is a pretty show-stopping bug IMOP until you discover the workarounds to enable software cursors for Mutter and Kwin in the comments above.

[lylythechosenone]

I enabled software cursors, but now I get really cursed mouse glitching. The mouse only appears when I move it around, and it often shows the wrong cursor. Hovering doesn't work right on a few things, and clicking on plasma panels doesn't work at all.

On the host, everything works completely fine. It's only using the mouse on Moonlight that everything breaks.

Without software cursors, it doesn't appear in Moonlight at all, but moves fine. With software cursors, it appears but moves erratically.

[Myned]

@lylythechosenone In my case, this is caused by enabling Remote desktop mouse mode in the Android app.

[kajdo]

just tried sunshine on arch sway as well as fedora server with x11 and minimal desktop setup.

on fedora/x11 i installed the latest rpm from this repo I do think i face the same issue - input is working as its supposed to, but mouse cursor is not visible (it works - because i can interact with it and see that buttons are pressed etc.)

[ReenigneArcher]

While, I can't speak to why it's disable, it appears to be intentional.

https://github.com/LizardByte/Sunshine/blob/455155a1c9172ee7ef2b75128c144ad076aea9e8/src/platform/linux/misc.cpp#L532-L537

[Smoukus]

While, I can't speak to why it's disable, it appears to be intentional.

https://github.com/LizardByte/Sunshine/blob/455155a1c9172ee7ef2b75128c144ad076aea9e8/src/platform/linux/misc.cpp#L532-L537

Unreliable sounds better than completely unavailable. That means that it might be visible for some users or usecases.

I suggest to set the variable display_cursor to true by default.

[gschintgen]

Is there a relation to the pointer that can be activated with Ctrl-Alt-Shift-M?

Because that one is indeed "unreliable": it disappears as soon as I stop moving the mouse and IIRC clicking doesn't work with it. That at least is too broken to be enabled by default. (The described behaviour is with windows client on gnome/wayland/amd host.)

On March 25, 2023 8:53:59 PM GMT+01:00, ReenigneArcher @.***> wrote:

While, I can't speak to why it's disable, it appears to be intentional.

https://github.com/LizardByte/Sunshine/blob/nightly/src/platform/linux/misc.cpp#L532-L537

-- Reply to this email directly or view it on GitHub: https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1483908961 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[KuleRucket]

While, I can't speak to why it's disable, it appears to be intentional. https://github.com/LizardByte/Sunshine/blob/455155a1c9172ee7ef2b75128c144ad076aea9e8/src/platform/linux/misc.cpp#L532-L537

Unreliable sounds better than completely unavailable. That means that it might be visible for some users or usecases.

I suggest to set the variable display_cursor to true by default.

You can show/hide the cursor after starting the session with ctl-alt-shift-n, but I agree. This seems to be inherited from the Loki version so it may not be unreliable any more for most people.

[kajdo]

i don't think that only wayland has a problem -- i didn't see any cursor on X11 as well

just found a solution created /etc/X11/xorg.conf.d/40-amd-sw-mouse.conf with following content to force sw-cursor

Section "Device"
    Identifier "graphicsdriver"
    Driver "amdgpu"
    Option "SWCursor" "true"
EndSection

after reboot cursor was visible

[KuleRucket]

@kode54 I have this too. But on the main desktop not just in sunshine. mesa is still a work in progress for the 7900 XTX.

On Wayland/KDE Plasma I force a SW cursor using this:

cat ~/.config/environment.d/mouse.conf 
KWIN_FORCE_SW_CURSOR=1

[ReenigneArcher]

You can download test builds with the mouse enabled here

Downloads will be available once the builds are complete. You must be logged in to GitHub in order to access the downloads.

I'm not able to test this myself, so would appreciate any reports of how reliable or unreliable the mouse cursor is.

[gschintgen]

You can download test builds with the mouse enabled here ... I'm not able to test this myself, so would appreciate any reports of how reliable or unreliable the mouse cursor is.

Hi, thanks for the test build! Unfortunately it doesn't work out 100%. The mouse behavior is quite strange: I opened the "Desktop" app just to see how the pointer behaves and I noticed that it was stuck in the Firefox window I happened to have open. When I tried to move it out of the browser's window on the client, the pointer in the client stayed inside Firefox, but on the host it did move fine. As soon as I (blindly) re-entered the Firefox window, the pointer worked fine again, but only inside the browser. (I had my laptop in front of the host so that I could compare both screens.)

In other words, it's not really usable on the desktop. In particular I can't properly interact with Ubuntu's Gnome dock or tray.

However the mouse seems to work fine in Steam and also in the first game I launched (Thimbleweed Park). But I can't recall right now what the state was before the patched build. I think it did not work, but I'd have to downgrade again to confirm. (I mainly use sunshine/moonlight for controller based games.)

What's the technical difference that could explain the discrepancy between Gnome and Steam? Maybe the former is a direct Wayland app whereas the second is handled via XWayland?

The test was done on: Host: Ubuntu 22.04.2, Gnome, Mesa 23.0 (kisak), edit: Wayland, AMD Client: Windows 10, latest Moonlight (4.3.1)

[gschintgen]

But I can't recall right now what the state was before the patched build.

I've just "downgraded" to the latest nightly and there too the mouse was working fine in Steam and in Thimbleweed Park. So the only apparent change for me (a positive one, fortunately) is that the mouse pointer is now working in Firefox, but it's still not usable for remote desktop usage.

(BTW I now have very weird behavior when executing systemctl --user start sunshine: immediately after hitting return, gnome's screen reader starts talking to me. It was a bit startling to have that unexpected voice coming out of the speakers. But this may well be unrelated to sunshine. I just post it here in case anyone else has that strange misbehavior which I may have to track down.)

[nlfog]

Just chiming in here to say that I had the same issue with the mouse not appearing on the client when streaming from Sunshine+Wayland. But, while introducing the KWIN_FORCE_SW_CURSOR=1 variable in ~/.config/environment.d/ worked to fix this, it caused other issues as I outlined in this Reddit post.. Will monitor this issue for resolution.

[zastrixarundell]

+1 on this issue. I'm using an RX 570 in Fedora Kinoite 38 and the latest flatpak of sunshine. I still can't see my mouse. Using software rendered mouse seriously botches my latency (it goes from 0.8ms to 50ms on LAN)

[stallmer]

(BTW I now have very weird behavior when executing systemctl --user start sunshine: immediately after hitting return, gnome's screen reader starts talking to me. It was a bit startling to have that unexpected voice coming out of the speakers. But this may well be unrelated to sunshine. I just post it here in case anyone else has that strange misbehavior which I may have to track down.)

@gschintgen Did you ever find a fix for this? I'm experiencing the same thing on Fedora 37. Gnome's screen reader starts as soon as I start sunshine. It also will not start sunshine after a reboot even after starting/enabling sunshine via systemd

[gschintgen]

(BTW I now have very weird behavior when executing systemctl --user start sunshine: immediately after hitting return, gnome's screen reader starts talking to me. It was a bit startling to have that unexpected voice coming out of the speakers. But this may well be unrelated to sunshine. I just post it here in case anyone else has that strange misbehavior which I may have to track down.)

@gschintgen Did you ever find a fix for this? I'm experiencing the same thing on Fedora 37. Gnome's screen reader starts as soon as I start sunshine. It also will not start sunshine after a reboot even after starting/enabling sunshine via systemd

No, sorry, I had no real need to investigate further. For me sunshine works just fine as a service (using a customized systemd unit specifying After=gnome-session.target). The screenreader issue only happens (happened?) when manually starting sunshine. I shrugged it off.

[escape0707]

I've heard from a systemd dev that it is because Gnome doesn't want to support xdg-desktop-autostart.target. And systmed specifically excluded Gnome or something. For me I just launch is via .desktop file. You can also modify that file to use systemd-run --user. After=gnome-session.target might work, too.