Closed Firlaev-Hans closed 8 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.
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.
Can't you enable/disable the mouse with the shortcut listed in the docs?
This won't be enabled by default.
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).
Does anyone have any theories regarding the source of this bug?
It's purposely disabled because the mouse behaves poorly.
Is there a way for sunshine to tell a client where the cursor is on the host?
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.
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.
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?
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.
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: @.***>
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
.
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.
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.
@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.
Still having this issue, still only able to resolve it using the "KWIN_FORCE_SW_CURSOR=1" workaround.
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.
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.
WTF? An actual heart beat comment got flagged as duplicated but the stale tag is still not automatically revoked?
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.
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
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.
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
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
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
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.
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
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 :
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 !
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
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
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.
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
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 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)
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!
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.
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.
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.
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.
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.
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:
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.
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.
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.
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!
You massive legend.
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.
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)