Sunshine
Sunshine copied to clipboard
LizardByte
Modifier keys "sticking"
Sometimes, the host PC will think Right Click, Ctrl, Alt, Win, or Shift are held down when they are not.
This happens infrequently, but I use Sunshine every day for remote desktop purposes and bump into this bug several times a week.
I cannot reproduce this on demand.
This might be related to, or is the same problem as another issue I'm seeing, which is 100% reproducible:
https://stefansundin.github.io/altdrag/
Try using AltDrag over sunshine. AltDrag will never see key_release for mouse left and right click!
This buggy behavior is also present in other window management utilities that utilize the mouse in some click n drag fashion.
Thanks and good luck squashing this one!
Host Operating System
Windows 10
Sunshine commit or version
0.18.3
Package
Windows - installer
Further oddities:
If you use AHK on the sunshine host like so, everything works as expected. Namely, you can click and drag.
Alt::LButton
But when used like this, KeyWait (wait for the release of Alt) never triggers. It appears Sunshine never receives the key-up event from moonlight. Thus, the code here will hold down left click forever when alt is pressed.
Alt:: {
Click 'L' 'D'
KeyWait 'Alt'
Click 'L' 'U'
}
This seems likely to be related to the inconsistent problem I've been having with modifiers getting stuck. Also, I've been having right click get stuck a lot, too! I'll update the first post with that.
Note: the use of Alt here has been for demonstration purposes. I have tested other mundane keys and they all trigger this behavior.
I have noticed this myself with alt-snap (https://github.com/RamonUnch/AltSnap), the continued version of alt-drag. I came here to report this exact bug. Right now, it is occurring 100% of the time when I drag a window, forcing me to either not use altsnap (which makes Windows unusable to me, honestly) or to enter RDP to kill the process so as to continue to use Moonlight.
This does not occur in Geforce Experience sharing and is Sunshine specific.
Yeah, I'd really like to use a few similar tools that are all currently mangled by this.
But even just for basic use: just the other day I was in the middle of typing up something and Shift got stuck 😩 Usually I can tap the affected key to unstick it (if I can figure out which one is being held to create whatever odd behavior I'm seeing), but for whatever reason I could not get shift to release, even after multiple disconnect/reconnects!
I was forced to swap over to RDP to continue typing, where everything worked as expected.
Worth repeating: the stuck key persisted across disconnect/reconnect. I'll try restarting the sunshine service next time to see if that helps.
I have also reported this problem here: https://github.com/RamonUnch/AltSnap/issues/380
Here's a wild shot in the dark...
The only time I've seen a key sticking problem was when the signal strength on my bluetooth keyboard to the adaptor wasn't strong enough. Switching to a class 1 (long range) bluetooth adapter solved it for me.
That's definitely not the issue. I have the issue on my iPad with a physically attached keyboard+mouse (magic keyboard).
I believe this issue needs to be solved by Microsoft. I think this is OS specific to Windows. I have experienced this issue with windows 10 and 11 since the day I got my first laptop all the way through to present day. Real keyboard and mouse works fine. Touch keyboard, on screen keyboard, virtual keyboards do not work. This issue has been reported inside windows feedback hub. People commenting and answering people's questions are not actually attempting to replicate the issues as reported correctly and every single time I find the same issue but different thread there is a bunch of hate and misinformation.
For example people say if you accidentally toggled sticky keys on with shift 5x all you need to do is go to control panel -> keyboard toggle use sticky keys on and off. Then go to settings -> keyboard and mouse -> toggle sticky keys on and off. Ensure every location that has sticky keys option is off as there are a couple or a few locations where the same exact setting may be found. This isn't a solution but Microsoft "experts" seem to believe it is.
I believe this issue needs to be solved by Microsoft. I think this is OS specific to Windows. I have experienced this issue with windows 10 and 11 since the day I got my first laptop all the way through to present day. Real keyboard and mouse works fine. Touch keyboard, on screen keyboard, virtual keyboards do not work. This issue has been reported inside windows feedback hub. People commenting and answering people's questions are not actually attempting to replicate the issues as reported correctly and every single time I find the same issue but different thread there is a bunch of hate and misinformation.
For example people say if you accidentally toggled sticky keys on with shift 5x all you need to do is go to control panel -> keyboard toggle use sticky keys on and off. Then go to settings -> keyboard and mouse -> toggle sticky keys on and off. Ensure every location that has sticky keys option is off as there are a couple or a few locations where the same exact setting may be found. This isn't a solution but Microsoft "experts" seem to believe it is.
I do not believe that this is an issue that should be ignored by Sunshine.
Although it may originate from a Windows issue (do we know this? I don't know if we do), since this issue is Sunshine specific, and using Moonlight with the official server implementation by Nvidia does work, there is clearly some way to fix this issue.
If there is indeed an issue on the Windows side, we may have to wait for years (there's bugs in Windows that are over a decade old!) before it gets any attention, so I would propose finding a solution in the way the Nvidia server software clearly did.
Definitely don't ignore this issue. I'm not attempting to suggest otherwise.
The issue is present with Nvidia gamestream. The issue is present during the out of box experience of windows during installation of the operating system to your computer when using the touch keyboard. This is not sunshine specifc issue.
If I somehow am talking about a different keyboard you can tell me. From what I know sunshine doesn't even have anything but an input passthrough feature to allow input communication to communicate between server and host. Maybe when you're using a real keyboard on your client pc/device the information that is communicated to the host pc is using a certain driver or channel that is currently bugged on windows. Maybe we just need to use a different driver/channel to solve the issue.
Perhaps there's a better submodule to use or a better way to implement the feature. There are many ways to potentially solve the issue but the only way to fix it is for someone to open a pull request that somehow effects this issue either positively or negatively and the root problem is discovered then solved.
Definitely don't ignore this issue. I'm not attempting to suggest otherwise.
The issue is present with Nvidia gamestream. The issue is present during the out of box experience of windows during installation of the operating system to your computer when using the touch keyboard. This is not sunshine specifc issue.
If I somehow am talking about a different keyboard you can tell me. From what I know sunshine doesn't even have anything but an input passthrough feature to allow input communication to communicate between server and host. Maybe when you're using a real keyboard on your client pc/device the information that is communicated to the host pc is using a certain driver or channel that is currently bugged on windows. Maybe we just need to use a different driver/channel to solve the issue.
Perhaps there's a better submodule to use or a better way to implement the feature. There are many ways to potentially solve the issue but the only way to fix it is for someone to open a pull request that somehow effects this issue either positively or negatively and the root problem is discovered then solved.
You are talking about a different issue entirely, I think. The issue myself and op are talking about works with Gamestream, but does not work with Sunshine.
Testing on my iPad less than an hour ago - with Sunshine, altsnap/altdrag does not release alt on unpress, which is the bug in question. With Gamestream, it releases alt on unpress as expected.
There is therefore a difference in how inputs are handled between Sunshine and Gamestream that is causing this differentiated behavior.
The issue is present with Nvidia gamestream. The issue is present during the out of box experience of windows during installation of the operating system to your computer when using the touch keyboard. This is not sunshine specifc issue.
You are definitely describing something else entirely. I don't know what you are describing; AltSnap/AltDrag and other such things work fine with the on screen keyboard. Additionally, they work fine over Remote Desktop as well as nvidia gamestream.
While I wish you luck solving your issue, let's not clutter discussion of this sunshine specific bug.
Back on topic: here is an additional context where sunshine's input isn't quite working right:
I have my laptop touchpad 4-finger-swipes bound to Win+Ctrl+Left and Win+Ctrl+Right through Windows own precision touchpad settings.
(I configure this because it allows me to swap virtual desktops on remote hosts, and in local usage it switches virtual desktops without invoking the (usually laggy) animation.)
When doing this gesture over sunshine, the start menu pops up 🤔 Keys aren't sticking in this example, but something is Not Quite Right :tm: and perhaps is related.
Although the latest version says lists "(Input/Windows) Fix issue where internation keys were not translated correct, and modifier keys appeared stuck" in the changelog, the issue sadly still remains.
Although the latest version says lists "(Input/Windows) Fix issue where internation keys were not translated correct, and modifier keys appeared stuck" in the changelog, the issue sadly still remains.
I think it fixed a separate (similar) issue. https://github.com/LizardByte/Sunshine/pull/975
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.
I have stopped using sunshine for RDP because of this issue, so I cannot currently comment on the state of SHIFT getting stuck while typing and so on.
But running through my three tests as documented above shows that the issue has potentially transformed.
- AltSnap: ❌ behavior unchanged
- Touchpad mapping: ✔️ start menu no longer appears
- AHK Script: ❌ still misbehaving, but in a different way now.
To refresh everyone's memory, the following script should effectively rebind alt into left mouse click. I previously stated,
KeyWait (wait for the release of Alt) never triggers. It appears Sunshine never receives the key-up event from moonlight. Thus, the code here will hold down left click forever when alt is pressed.
Now, however, the script will not hold down Click, and is sending Click twice, 100% of the time.
;This function runs when alt pressed
Alt:: {
Click 'L' 'D' ;This sends mouse left click down
KeyWait 'Alt' ;This waits for Alt to be released
Click 'L' 'U' ;This sends mouse left click up
}
After some tinkering, I can see what's going on. With the following script, the function only triggers on Alt release. Thus, AHK never receives the Alt-is-pressed event. A popup fires to signal the function has started. After dismissing the popup, the function sleeps for 3s and then left clicks once. It should be holding left click, but it isn't. 3s after the next popup, left click should be released, but instead it is detected as another click.
;This function runs when alt pressed
Alt:: {
Msgbox 'Left click down 3s after dismissing this window!'
sleep 3000
Click 'L' 'D' ;This sends mouse left click down
Msgbox 'Left click release 3s after dismissing this window!'
sleep 3000
Click 'L' 'U' ;This sends mouse left click up
}
🎉🎉🎉 Latest release v0.21.0 fixes altsnap! (Or the latest accompanying moonlight does) 🎉🎉🎉
AltSnap: ✔️ 🥳 Touchpad mapping: ✔️ 🥳 AHK Script: ❌ misbehaving
The incorrect AHK behavior remains, but I would personally consider that super low priority. I don't know if this edge case will ever occur outside of AHK.
I will resume using moonlight again and report back if the titular issue crops up (shift/alt/ctrl etc sticking). I have a feeling it won't :)
Ah, my guess as to why it was fixed on my end (for AltSnap anyway) was that I am on nightlies. It is good to know that the formal release with the fix has reached the general public.
Not sure if this is related, but I've just noticed that WinCompose on the client seems to be entirely undetected by moonlight or sunshine. If WinCompose is controlling capslock, for instance, the host only receives lowercase. The host also does not receive any given composed character.
This is also not particularly important to fix- just adding another data point to the pile.
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
I spoke too soon re: touchpad mapping. It does still invoke the start button, somehow, but now it sends the key twice, so I see the start menu flash as I use my three finger touchpad gestures.
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
This issue was closed because it has been stalled for 10 days with no activity.