No Mouse Input on Nightly Builds in Fedora 40 #2971
Comments
|
Is the user running sunshine part of the input group? |
Yep!
|
|
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. |
|
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. |
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. |
|
A few questions:
|
|
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: 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
4bd521b
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
min_threads = 4 qp = 25 fec_percentage = 40 min_fps_factor = 10 audio_sink = alsa_output.usb-M-Audio_AIR_192_4-00.analog-stereo fps = [30,60,90,120,144,240] nv_preset = default amd_quality = default amd_rc = auto sw_preset = veryfast sunshine_name = EmpokNor channels = 2 nv_rc = auto key_rightalt_to_key_win = enabled origin_pin_allowed = lan resolutions = [ 1280x720, 1920x1080, 2560x1440 ] output_name = 2Apps
No response
Relevant log output
The text was updated successfully, but these errors were encountered: