search

LizardByte / Sunshine

Self-hosted game stream host for Moonlight.
http://app.lizardbyte.dev/Sunshine/
GNU General Public License v3.0
17.52k stars 849 forks source link

KDE Plasma Wayland: Mouse cursor is not visible #93

Closed Firlaev-Hans closed 8 months ago

Firlaev-Hans commented 2 years ago

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)

winnbarr185 commented 1 year ago

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.

ReenigneArcher commented 1 year ago

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

This won't be enabled by default.

winnbarr185 commented 1 year ago

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

winnbarr185 commented 1 year ago

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

ReenigneArcher commented 1 year ago

It's purposely disabled because the mouse behaves poorly.

winnbarr185 commented 1 year ago

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

billksun commented 1 year ago

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.

escape0707 commented 1 year ago

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.

winnbarr185 commented 1 year ago

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?

escape0707 commented 1 year ago

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.

lylythechosenone commented 1 year ago

Using xdg for this would be super cool indeed. It seems to be the best way to do screenshare on Wayland.

On Tue, Jun 20, 2023 at 1:59 AM Escape0707 @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1598161964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVFKGKVDEJT57WI6AE2MGTXME34DANCNFSM5QRXBN2Q . You are receiving this because you were mentioned.Message ID: @.***>

billksun commented 1 year ago

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

escape0707 commented 1 year ago

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.

winnbarr185 commented 1 year ago

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.

tjssoldier commented 1 year ago

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

queenbiscuit311 commented 1 year ago

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

LizardByte-bot commented 11 months ago

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.

pacjo commented 11 months ago

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.

escape0707 commented 11 months ago

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

ReenigneArcher commented 11 months ago

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.

typester commented 11 months ago

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

escape0707 commented 11 months ago

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.

ReenigneArcher commented 11 months ago

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

Jacqueb-1337 commented 11 months ago

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

ReenigneArcher commented 11 months ago

These are workarounds:

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1165021055

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1287885165

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1374964995

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1483938743

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1483941690

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1503331019

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1624793386

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1749847714

escape0707 commented 11 months ago

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.

Jacqueb-1337 commented 11 months ago

These are workarounds:

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1165021055

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1287885165

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1374964995

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1483938743

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1483941690

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1503331019

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1624793386

https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1749847714

I could kiss you

SweatnR commented 11 months ago

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 !

sniirful commented 10 months ago

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

osiox commented 10 months ago

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

queenbiscuit311 commented 10 months ago

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.

osiox commented 10 months ago

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

ReenigneArcher commented 10 months ago

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.

osiox commented 10 months ago

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 5f25dd6d82ba18db7b235b02d99ddfb25bb569b8 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)

halcyonhippo commented 9 months ago

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!

sniirful commented 9 months ago

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

queenbiscuit311 commented 9 months ago

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.

sniirful commented 9 months ago

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.

queenbiscuit311 commented 9 months ago

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.

JeffersonTan commented 9 months ago

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:

queenbiscuit311 commented 9 months ago

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.

AimForNaN commented 8 months ago

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.

pacjo commented 8 months ago

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.

JustPlainGarak commented 8 months ago

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!

nixRidge commented 8 months ago

You massive legend.

j-landru commented 5 months ago

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 https://github.com/LizardByte/Sunshine/issues/93#issuecomment-1165021055, 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.