KDE Plasma Wayland: Mouse cursor is not visible about sunshine HOT 96 CLOSED

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.

from sunshine.

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.

from sunshine.

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.

from sunshine.

It actually works now! Tested https://github.com/LizardByte/Sunshine/actions/runs/7429573380 (flatpak version) with android and flatpak (on ubuntu gnome) moonlight clients.

Thanks @cgutman and everybody else who worked on it for finally fixing this.

from sunshine.

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.

from sunshine.

This issue is stale because it has been open for 90 days with no activity. Comment or remove the stale label, otherwise this will be closed in 10 days.

from sunshine.

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?

from sunshine.

This issue is stale because it has been open for 90 days with no activity.

What? No, no, no. This isssue is as alive as always.

from sunshine.

I've linked old build by replying to a comment, but I've not tested that one. I am testing the same patch, but applied to latest version of 'nightly' branch - so not the same as the link above :)

The previous build was from 2023.03.26 so there is a possibility that the cursor improved because of changes done to other "pieces" - wayland, sway, whatever. Or maybe it just works for me :x

also I've tried this patch and it works fine. I feel like this should be enabled by default, because any bugginess this could cause can't possibly be worse than the complete unusability of this program without a visible mouse cursor in most situations and the problems caused by using a software cursor. At least a toggle in the settings or something would be nice.

from sunshine.

For the people using GNOME, I seem to have found a better workaround. Just go to your accessibility settings and enable Zoom with a magnification factor of 1.00. I also enabled the Accessibility Menu so whenever I'm using Sunshine I enable the Zoom feature, when I don't need it anymore I can disable it.

This seems to be better because it doesn't leave mouse trails as MUTTER_DEBUG_DISABLE_HW_CURSORS=1 does. On the other hand, the cursor doesn't seem to be animated.

from sunshine.

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)

from sunshine.

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

from sunshine.

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

from sunshine.

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.)

from sunshine.

@winnbarr185 OBS use pipewire capture on wayland, something that sunshine have no support currently. I think that using pipewire could solve this problem with the mouse and give better compatibility on wayland for the appimage and flatpak versions.

But we need someone to implement this.

from sunshine.

Still having this issue, still only able to resolve it using the "KWIN_FORCE_SW_CURSOR=1" workaround.

from sunshine.

Watch your attitude.

The stale will be removed on the next check.

Also, the comment was hidden because it was rude, and I didn't feel like marking it as abuse... but I guess that is the route I will go from now on.

from sunshine.

These are workarounds:

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

from sunshine.

I just found another "workaround" for GNOME. If you start a screen recording using the GNOME built-in screen recorder, the cursor is shown for Sunshine as well. It also unfortunately shows a ghost cursor sometimes.

This is something the Sunshine devs might consider to replicate from GNOME

from sunshine.

Also confirmed working on Fedora 39 using the nightly-dev build from today (Jan 6 2024). Big thanks to everyone who contributed to this fix!

from sunshine.

You massive legend.

from sunshine.

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.

from sunshine.

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.

from sunshine.

Works in nightly

from sunshine.

@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.

from sunshine.

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.

from sunshine.

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

from sunshine.

from sunshine.

(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

from sunshine.

(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.

from sunshine.

I had the same issue as well. My setup is Arch, Hyprland, AMD GPU.

In my environment, setting WLR_NO_HARDWARE_CURSORS=1 temporarily solves the problem. This should likely work on Sway too. JFYI

from sunshine.

Watch your attitude.

There is zero need to escalate this to an "altitude" level of a problem. Old GitHub users might have seen this kind of stale bot a lot and used these ping chances to make various jokes of the bot without losing the original goal of making a comment following it, that is, to tell the developers CI system that this issue is still being watched by a living human.

If they didn't bother to use up maybe half of a minute in their life to do that, someone else might have to. And you didn't. Though tiny, it is still a contribution.

The situation left for other community members to see during that period is indeed what I've described. The ping comment got marked hidden, and users don't know if it's some auto filtering algorithm that triggered this behavior by mistake, or if it's actually marked by a developer. In either case, this is unexpected and makes me surprised to think "WTF" in my mind, because in the previous case, the auto management system's design is humorously flawed and needs a fix, in the latter case, the stale tag still being there after human moderation is definitely not usually seen in the open source community.

I really don't like your reply that implies me and the other people have any altitude problems. We are here trying to help the process of issue management, report new issues and raise appropriate attention to issues that need that the most. Normal repo's bot will simply remove the stale tag immediately and maybe even leave a reply as a notice, and the dev won't need to and actually don't do anything. I'm a simple person, I saw a surprising situation, I'm surprised and thought WTF in my mind, and I simply typed it. No complex intentions involved. I think you might be being too sensitive here. After all, if it turns out that an actual human is marking the ping comment as hidden without removing the stale status at all, this is what I see as rude exactly.

Although forced to add this off topic defense to the thread, I hope you don't think offended again, as I have neither the intent nor the energy for any drama. If you insist that what you've done is okay, then be it. It's you guys' repo anyway.

from sunshine.

GitHub's stale action does not watch issues in real-time. It's an action that runs on a schedule. Anyway...

This will be the last comment on this issue regarding the dislike of the automations in our repositories, the stale action, hidden comments, or anything not related to a mouse cursor being not visible... otherwise this issue will be locked. This has already wasted enough time... a simple "bump" or "still an issue" is sufficient, without snarky comments. Our community guidelines are here: https://docs.lizardbyte.dev/en/latest/developers/code_of_conduct.html

from sunshine.

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.

from sunshine.

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

from sunshine.

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.

from sunshine.

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?).

from sunshine.

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).

from sunshine.

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.

from sunshine.

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.

from sunshine.

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.

from sunshine.

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.

from sunshine.

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

from sunshine.

No software cursor workaround available for Gnome.

from sunshine.

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.

from sunshine.

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

from sunshine.

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

from sunshine.

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.

from sunshine.

@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.

from sunshine.

@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

from sunshine.

@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.

from sunshine.

@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.

from sunshine.

@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.

from sunshine.

Have the same issue.

from sunshine.

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?

from sunshine.

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.

from sunshine.

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.)

from sunshine.

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

Sunshine/src/platform/linux/misc.cpp

Lines 532 to 537 in 455155a

	if(verify_kms()) {
	if(window_system == window_system_e::WAYLAND) {
	// On Wayland, using KMS, the cursor is unreliable.
	// Hide it by default
	display_cursor = false;
	}

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.

from sunshine.

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

Sunshine/src/platform/linux/misc.cpp

Lines 532 to 537 in 455155a

	if(verify_kms()) {
	if(window_system == window_system_e::WAYLAND) {
	// On Wayland, using KMS, the cursor is unreliable.
	// Hide it by default
	display_cursor = false;
	}

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.

from sunshine.

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

from sunshine.

@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

from sunshine.

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.

from sunshine.

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.

from sunshine.

+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)

from sunshine.

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.

from sunshine.

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.

I tested this on my intel core 1185g7 system running fedora 38 with kde wayland and a windows client and my experience is similar to that of @gschintgen when they tested the patch (I selected the "desktop" while I had a game running). Input from the remote system is fine but as mentioned in their report, cursor only appears correctly when used with steam and games launched from it (the cursor remained stuck in place outside of steam and games) based on my limited test. You could try mainlining this as it is better than nothing even with the issues mentioned. I had to undo the patch as h264 hardware encode (intel vaapi) quality was poor on that version of sunshine.

from sunshine.

Can't you enable/disable the mouse with the shortcut listed in the docs?

This won't be enabled by default.

from sunshine.

Can't you enable/disable the mouse with the shortcut listed in the docs?

This won't be enabled by default

It looks like pressing ctrl+alt+shift+N causes the same thing I described in my previous comment where the clientside cursor only moves and displays correctly with the cursor is on the host when using steam or an application launched by steam (and after a little more testing, waydroid as well).

from sunshine.

Does anyone have any theories regarding the source of this bug?

from sunshine.

It's purposely disabled because the mouse behaves poorly.

from sunshine.

Is there a way for sunshine to tell a client where the cursor is on the host?

from sunshine.

I have this issue too.

The reason why the cursor displays on steam and steam applications, is because those applications are drawn by X server rather than Wayland. If you have an electron application, it most likely will display the cursor as well, because most electron apps do not run natively in Wayland yet.

So this definitely is an issue with capturing cursor on Wayland.

from sunshine.

Is there a way for sunshine to tell a client where the cursor is on the host?

Not really under Wayland now. And that's why we have this issue in the first place.

But I do wish moonlight's "optimize remote desktop to show local cursor instead of remote one" work better. The last time I checked it, it doesn't work when both the remote and the local client are using Linux Wayland IIRC.

from sunshine.

Not really under Wayland now. And that's why we have this issue in the first place.

Is there work towards addressing this in the Wayland protocol and are any of the major Wayland DEs involved?

from sunshine.

Not really under Wayland now. And that's why we have this issue in the first place.

Is there work towards addressing this in the Wayland protocol and are any of the major Wayland DEs involved?

At a second thought, I think it would be better for a developer of Sunshine to explain the situation rather than me. Although I do think RustDesk used the xdg-desktop-portal to do this.

from sunshine.

from sunshine.

Although I do think RustDesk used the xdg-desktop-portal to do this.

RustDesk only uses xdg-desktop-portal to do screen recording/casting on Wayland, not for sending inputs.

Instead, RustDesk uses uinput under Wayland for input support, which requires sudo.

See: https://github.com/rustdesk/rustdesk#wayland-support

from sunshine.

not for sending inputs.

Instead, RustDesk uses uinput

uinput is exactly what Sunshine has been using for emulating user input according to the setup guide. This issue is about getting current cursor location or recording along with the screen. Which I don't know if is doable with x-d-p.

from sunshine.

When I use OBS, it can capture the screen and the cursor just fine under wayland so maybe if we can figure out what they did that enables the cursor to be captured as well then maybe this can be implemented in sunshine.

from sunshine.

WTF? An actual heart beat comment got flagged as duplicated but the stale tag is still not automatically revoked?

from sunshine.

Did anyone find a good fix for this? Sorry if it has been said in an earlier comment, I didn't feel like sorting through all the drama..

I'm on ChimeraOS (arch) using Wayland

from sunshine.

Thank you for gathering the info. But I just want to add a notice that, if you choose to use the pretty limited software cursor workaround (only available if your compositor support this feature), you'll more than likely notice some delay in the using of the SW cursor. Plus you won't be seeing the cursor if an application goes to dedicated fullscreen mode.

from sunshine.

These are workarounds:

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

#93 (comment)

I could kiss you

from sunshine.

Hello all,

I installed Debian 12 Bookworm with Linux kernel 6.1 version 686 .
X11 is still installed. Before Sway was running on top of i3 config, then encountered the cursor issue, so purged i3 and Sway, and lastly, re-installed Sway 1.7. After looking the man 5 sway-input and the internet ; Typester's comment is the fix working for me :

#93 (comment)

Addingthe line : "WLR_NO_HARDWARE_CURSORS=1" in /etc/environment , which was actually empty so I just put in top of the file.

Successfully retrieved my touchpad's cursor, and no bug for now (a few hours ago) .

Thanks you !

from sunshine.

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.

Not sure why the cursor is unreliable for others.
I've changed display_cursor to "true" on nightly branch and I will stay on this "custom version" as it works exactly as it should. On my setup the cursor is not stuck, is displayed in correct place etc.

Can we have this configurable (without using the 'shortcut') ? WebUI or maybe command line switch when launching sunshine or environment variable ?
I want the cursor when using moonlight android client and this 'true' would work for me - I do not have a keyboard connected to android to enable the mouse using shortcut ^.^

If not then no problem - I can just build it myself.
Although I would prefer to update sunshine by just installing latest deb, without the need to build anything :)

# Ubuntu 22.04 with Sway

from sunshine.

It might be a difference between wlroots, mutter, and kwin. I can test the build you linked as well an see if there's differing behavior

Not sure why the cursor is unreliable for others.

It might be a difference between different compositor types such as wlroots, kwin, and mutter. I can try this build myself and see if theres any difference.

from sunshine.

It might be a difference between wlroots, mutter, and kwin. I can test the build you linked as well an see if there's differing behavior

Not sure why the cursor is unreliable for others.

It might be a difference between different compositor types such as wlroots, kwin, and mutter. I can try this build myself and see if theres any difference.

I've linked old build by replying to a comment, but I've not tested that one.
I am testing the same patch, but applied to latest version of 'nightly' branch - so not the same as the link above :)

The previous build was from 2023.03.26 so there is a possibility that the cursor improved because of changes done to other "pieces" - wayland, sway, whatever. Or maybe it just works for me :x

from sunshine.

I will add that wayland/wlr protocols have been updated and are now submodules, although I don't believe there were actually any changes there that would improve this situation.

from sunshine.

I will add that wayland/wlr protocols have been updated and are now submodules, although I don't believe there were actually any changes there that would improve this situation.

I've built 5f25dd6 and it still works correctly for me, so I do not think that it was fixed by wayland/wlr protocols update in the repository.

There was a comment about firefox:

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.

I was unable to reproduce this in my setup. It basically works by sending the cursor as a part of video stream I think? And the cursor is in correct place. I've played around with Vivaldi browser, Firefox, Gedit and I've launched one game via steam - no issues in any of them.

Host: Ubuntu 22.04, Sway WM (version 1.7)
Client A: Moonlight Android
Client B: Moonlight PC v5.0.1 (running on Linux Mint)

from sunshine.

I am having the same issue from Android Moonlight client v12.0.2. Both with Sunshine v0.20.0 and now v0.21.0 from the RPM provided in this repo's releases for Fedora 38. This is on Fedora under GNOME/wayland. I have not tried the software cursors workaround yet as I'm not sure that's going to be a long term solution.

Here are my system deets:

OS: Fedora Linux 38 (Workstation Edition) x86_64 
Kernel: 6.5.10-200.fc38.x86_64  
Shell: bash 5.2.15 
Resolution: 3840x2160 
DE: GNOME 44.6 
WM: Mutter 
WM Theme: Adwaita 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: gnome-terminal 
CPU: AMD Ryzen 7 5800X3D (16) @ 3.400GHz 
GPU: AMD ATI Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT
Memory: 5312MiB / 31986MiB 

Edit: Just tried the GNOME/mutter workaround provided by akhil-rana above, setting MUTTER_DEBUG_DISABLE_HW_CURSORS=1 in /etc/environment and now the cursor appears. Not sure what other side effects this will have since it is applied at the top level like this, but I guess I'll use this as a band-aid for now. Looking forward to any updates/fixes for this in the future!

from sunshine.

For the people using GNOME, I seem to have found a better workaround. Just go to your accessibility settings and enable Zoom with a magnification factor of 1.00. I also enabled the Accessibility Menu so whenever I'm using Sunshine I enable the Zoom feature, when I don't need it anymore I can disable it.

This seems to be better because it doesn't leave mouse trails as MUTTER_DEBUG_DISABLE_HW_CURSORS=1 does. On the other hand, the cursor doesn't seem to be animated.

Screencast.from.2023-11-11.03-50-54.webm

Can confirm that this did indeed work, although I needed to restart to fix mouse controls. not sure if thats entirely related or not. It does nuke your refresh rate if running over 60hz (haven't tested 60hz by itself) until it's turned off, but works if you absolutely need mouse support. It also seems to make the mouse a bit buggy in terms of cursor images. for me the mouse would randomly just not switch back from the window resize cursor within a window for a bit.

from sunshine.

It does nuke your refresh rate if running over 60hz (haven't tested 60hz by itself) until it's turned off, but works if you absolutely need mouse support.

I unfortunately cannot test refresh rates higher than 60 Hz so for me it worked directly.

It also seems to make the mouse a bit buggy in terms of cursor images. for me the mouse would randomly just not switch back from the window resize cursor within a window for a bit.

I noticed the cursor misbehaves only in X11 applications (e.g. VSCode) while in Wayland apps it works 100% except for the animations.

from sunshine.

I unfortunately cannot test refresh rates higher than 60 Hz so for me it worked directly.

It could also maybe be Wayland support for my hardware which has always been a bit screwy with refresh rates, but it's probably better at 60hz.

I noticed the cursor misbehaves only in X11 applications (e.g. VSCode) while in Wayland apps it works 100% except for the animations.

That makes sense, I'll have to test that next time I need to use this.

from sunshine.

For the people using GNOME, I seem to have found a better workaround. Just go to your accessibility settings and enable Zoom with a magnification factor of 1.00. I also enabled the Accessibility Menu so whenever I'm using Sunshine I enable the Zoom feature, when I don't need it anymore I can disable it.

This seems to be better because it doesn't leave mouse trails as MUTTER_DEBUG_DISABLE_HW_CURSORS=1 does. On the other hand, the cursor doesn't seem to be animated.
Screencast.from.2023-11-11.03-50-54.webm

Just tested it and this workaround works for me

System:

• AMD Ryzen™ 5 5600G with Radeon™ Graphics × 12
• AMD Radeon™ RX 6600
• Nobara Linux 38 (Thirty Eight)
• GNOME 44.2 on Wayland
• Linux 6.5.9-201.fsync.fc38.x86_64

from sunshine.

My host setup is Arch Linux with Hyprland on an AMD GPU. I installed sunshine using the AUR package. I tried the suggestion here, but it didn't help. Running systemctl --user show-environment correctly lists the env var.

Edit: Had to set the environment var in the hyprland config.

from sunshine.

KWIN_FORCE_SW_CURSOR=1

On Alpine (which is not a sytemd, but openrc dsitrib) with Qt 6.6.2, Kde Plasma 6.0.2 and sddm as display manager I confirm, as stated in #93 (comment), that .profile or /etc/profile.d scripts have no effect. But setting export KWIN_FORCE_SW_CURSOR=1 in /usr/share/sddm/scripts/wayland-session file was the way for me to recover the mouse cursor in a kwin_wayland session.

Also if you need sddm-greeter in wayland mode, you have also to set that env var in sddm conf file to have a mouse cursor on sddm greeter display. Here my /etc/sddm.conf.d/05-sddm-abcd-wayland.conf example file inspired from https://wiki.gentoo.org/wiki/SDDM.

[General]
DisplayServer=wayland
GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell,KWIN_FORCE_SW_CURSOR=1

[Wayland]
CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1

Hoping this can be useful for others.

from sunshine.