ReenigneArcher
commented
1 month ago Is the user running sunshine part of the input group?
Closed JustPlainGarak closed 12 hours ago
ReenigneArcher
commented
1 month ago Is the user running sunshine part of the input group?
JustPlainGarak
commented
1 month ago Is the user running sunshine part of the input group?
Yep!
[JustPlainGarak@EmpokNor~]% cat /etc/group | grep input
input:x:104:JustPlainGarak
ReenigneArcher
commented
1 month ago I assume it's related to this change: https://github.com/LizardByte/Sunshine/pull/2606
JustPlainGarak
commented
1 month ago I assume it's related to this change: #2606
Oh, that could certainly be the case. I'll swap back to the pre-release build and see if the udev rule and uhid module load files get added with the installation. If they DON'T get added, I'll create them myself, reboot and see what the result is. Either way, I'll report the results of that process here once completed.
JustPlainGarak
commented
1 month ago Unfortunately, I am still seeing the same behavior. I updated to the Aug 5th build again, set the udev rule, set the module to load at boot and rebooted the computer.
While the uhid module loaded (confirmed with lsmod and /proc/modules), no mouse input registers on the host PC. Keyboard and controller input continue to work as they did previously.
gschintgen
commented
1 month ago You seem to be comfortable building Sunshine from source. You could try building it once after checking out commit 509576d61608925deb6f2360a5f5cba9521a71fb (merge commit of the new input system) and once with the previous commit. That should be 5f1a17f77d4bc2f29d4d7b6bfc9f0e0b913fcddb.
For automatic loading of the uhid module see #2906
JustPlainGarak
commented
1 month ago You seem to be comfortable building Sunshine from source. You could try building it once after checking out commit 509576d (merge commit of the new input system) and once with the previous commit. That should be 5f1a17f.
For automatic loading of the uhid module see #2906
Here are my results from testing the two commits:
I think that confirms the general suspicion that something in the new input system merged in with 509576d is breaking virtual mouse input, at least on my system.
I'd already setup the module auto-load for uhid yesterday and confirmed the module is (and was during testing) loaded with lsmod and /proc/modules (at least I'm pretty sure that's what these outputs mean). Here's the output from them for reference.
sudo lsmod | grep uhid
uhid 24576 1
sudo cat /proc/modules | grep uhid
uhid 24576 1 - Live 0x<what I assume is a memory address>
ABeltramo
commented
2 weeks ago uhid is just used for emulating the PS5 joypad with Gyro and acceleration, everything else uses /dev/uinput.
A few questions:
udevadm monitor before starting the stream and check which events (if any) gets triggered by starting the stream? evemu-record (it's under evdev-tools I believe on Debian, not sure under Fedora) and check if whilst running a Sunshine stream it lists additional virtual devices and it does receive any input?
Specifically, which udev rules have you installed?JustPlainGarak
commented
12 hours ago Alright, well...
I just spent the last 2 hours trying to reproduce the issue, gathered logs for the requests from @ABeltramo and all that jazz...but the issue is gone and I can't make it come back. I thought that maybe, somehow, installing evemu had fixed the issue, but removing the package had no effect: my mouse simply works now. This isn't only with the latest nightly, I also installed the August 5th nightly I was testing with before and all inputs, mouse included, work fine now.
I can only assume that there was some now resolved upstream issue in Fedora that silently fixed this issue for me as I have no other explanation. For the sake of completeness, I will provide/confirm the following:
My udev rules:
[JustPlainGarak@EmpokNor~]% cat /etc/udev/rules.d/60-sunshine.rules
KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", TAG+="uaccess"
KERNEL=="uhid", TAG+="uaccess"The issue was only with the mouse. The keyboard and any/all controllers I threw at it worked just fine.
Thanks to everyone for the time and effort looking into this issue with me. I hate that I don't have root cause for us, but hey...at least the problem is gone?
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
Mouse input from clients (I have tested multiple client devices, all on the latest stable Moonlight AppImage build) does not move the mouse on the host PC running Fedora 40. This includes both movement and clicks.
The issue is present both in the automated builds available from github as well as a source built RPM from the latest master branch.
This issue is not present in v0.23.1 built from the master_legacy branch on my machine.
Expected Behavior
When I interact with the mouse on the client, those actions should occur on the host.
Additional Context
I enabled debug logging to see if I could find any errors, and as far as I can tell, there are none. I've put some of the log into the field below but will attach the full log file as well in the event that my cherry picking doesn't reveal something that the full log file does. sunshine-no-mouse-f40-v2024.805.184417-debug.log
Host Operating System
Linux
Operating System Version
Fedora Linux 40 (KDE Plasma)
Architecture
64 bit
Sunshine commit or version
https://github.com/LizardByte/Sunshine/commit/4bd521bb4360d8ba9b1af8d2d704e8f79c3e9a38
Package
Linux - rpm
GPU Type
AMD
GPU Model
AMD Radeon RX 7900 XTX
GPU Driver/Mesa Version
Mesa 24.1.5
Capture Method
KMX (Linux)
Config
Apps
No response
Relevant log output