Thanks for the report, are you using rtkit-daemon or configured ulimit so that the new priority mechanism work? Could you try with that disabled, by uninstalling rtkit-daemon and have 0 RLIMIT_NICE?
Same question with fsync / futex2, it would be nice if we can narrow this down a bit more.
I'm guessing this could be related to https://github.com/ValveSoftware/wine/commit/287781d90fff4b22dbed805b2a879ffa5ccbeafa#commitcomment-45900927, or some similar issue with driver processes that don't have any specific priority set and could so lag behind the game threads.
Yes, I'm actually using rtkit-daemon and configured ulimit for -15. I used similar patches in my custom-baked Proton back in version 3.x and 4.x but didn't experience such behavior there. Actually, I had one patch that increased priority of the input-related threads/drivers - not sure how wine (or Proton for that matter) changed since then. I'm also using a fsync / futex2 patched kernel (including MuQSS) but since multiple games show problems starting with futex2, I disabled it globally by a session environment variable.
BTW: I recently added a patchset for bcache which removes a system_wq workqueue congestion from the kernel, and it looks like this lag is no longer an issue in Wine/Proton. But it shows there's still a potential to get this which may somehow be related to the kernel event handler (system_wq): https://lore.kernel.org/linux-bcache/CAC2ZOYtrrOXD35ZWLer8R8n1dcyqGi_dipHp+y1JNt_eaue_9A@mail.gmail.com/T/#t
This kernel patch series is proposed for inclusion in 5.12 with backports back to 5.4+. I'm currently applying that on top of my 5.10 kernel.
These are my input driver patches I added to Proton:
I added these because I was seeing slow hotplug input device detection in demanding games, and missed input events (back when I played Tomb Raider, the trigger button often didn't engage the bow). It did improve things but didn't fix it. In the aftermath, that may have also been an instance of the system_wq congestion which has been introduced into bcache in 2014.
It will be useful to have a dedicated Proton Experimental thread for to report regressions.
@rbernon
are you using rtkit-daemon or configured ulimit so that the new priority mechanism work? Could you try with that disabled
I just found that I actually didn't enable that service for some unknown reason, so it has been inactive anyways. I'm going to observe the behavior for some time with it enabled.
Ignore that, it auto-spawns on dbus calls. Usually after system boot it had been running because some process triggered it - seems to happen no longer and thus I assumed it wasn't working at all. But looking back at older logs, it spawns when I play Proton games.
@rbernon Do you know if it would be enough to make all winedevice.exe threads highest priority for an artificial test? Actually, I did that (alt+tab out of the game, run schedutil -I -n -19 $(pgrep -w winedevice), cross-checked in htop that priority was changed successfully). But it didn't help the issue.
I'm not sure why that happens: Sometimes it just works, sometime the problem persists until I eventually reboot the system. While the game is running (and using CPU), I ran jstest and evtest to validate that the kernel sees input instantly: So lag doesn't come from the kernel.
I also disabled vsync and triple buffering to verify that I'm not just seeing delayed screen content.
The issue is currently different to why I initially reported it. I think my initial issue is actually some Bluetooth problem with my Elite 2 controller, I don't see that (delays of multiple seconds, input event loss) happen with my Xbox Series X controller. But there's still a constant lag of what feels like 200ms across all games I'm testing. In a fast paced shooter this feels like running around while drunk - somewhat funny but not very useful without actually being drunk. ;-)
Enabling futex2 only seems to make that worse (but the whole implementation seems to not work correctly for me, I get audio-dropouts and inconsistent frame rates when using futex2, so that's probably a different issue).
Mouse and keyboard input experiences the same lag, so it's not specific to the driver.
It looks like vkd3d games don't experience this issue...
Mouse and keyboard input is usually received by the application process itself, in the thread(s) that call Peek/GetMessage, and then there's a roundtrip to wineserver. The winedevice processes are only receiving gamepad input so far.
One exception for mouse input though, if the game uses rawinput, then some of the input is received in explorer.exe, which pushes it to wineserver, which in turn dispatches to the right application threads. In this case it will also depend on the application thread (possibly dinput thread if the game uses dinput) calling Peek/GetMessage.
Among these I only see explorer.exe, wineserver and the dinput thread for which increasing priority could make a difference. I don't think we should change the priority of the application threads themselves, but if they have a low priority and for some reason don't call Peek/GetMessage often enough, then it could be an issue.
Ah so I didn't re-read the initial message and I see now this was about gamepad input. So in this case the flow is indeed coming from winedevice.exe, which replies to (wine) ioctls, or pushes input messages to wineserver. In all cases there's wineserver involved in the middle, and ioctls / device read (used by xinput I think) is currently the worst as it involves multiple roundtrips from the application to wineserver and from winedevice.exe to wineserver.
Is this true for SDL patched Proton? As far as I could track it, winebus.sys directly interfaces with SDL, but I'm not sure how that integrates with xinput. Maybe I have to get back into some Proton development and testing patches... From your description, whatever winebus.sys does, lives in a winedevice.exe thread - and passing information between the game and winebus.sys has to go through wineserver? This sounds somewhat crazy to do. I can just guess this is about abstraction across different platforms but Proton is quite specifically for Windows games on Linux. Couldn't we just call from xinput right into the Linux APIs?
From your description, whatever winebus.sys does, lives in a winedevice.exe thread - and passing information between the game and winebus.sys has to go through wineserver?
Yes, that's correct.
Couldn't we just call from xinput right into the Linux APIs?
It possibly could for simple input but I think it would fail to work correctly in some cases, or be much more difficult to implement, for all the Windows internal interactions to work properly and consistently across processes.
It's clearly not ideal, and especially with the current overhead of things like reading HID reports from device files, but there are ways to make it better, it only needs time and effort to implement the required mechanisms.
I wonder if things could be improved if wineserver wouldn't be strictly single threaded: It could implement different threads to serialize independent subsystems individually instead of putting all and everything on the same queue. But that's probably not easy to implement either, maybe even impossible.
Can confirm for Slime Rancher 2, input lag of whole minutes.
Doesn't happen on Proton GE 8-32, tho. Does happen, but a lot less.
Happening for me now on a bunch of proton games, the longer I play the worse it gets. I was playing subnautica and it got to the point where input delays were around 30 seconds.
Edit: Looks like https://github.com/ValveSoftware/Proton/issues/5294#issuecomment-1236124959 is relevant, going to see if this fixes my issue. I think my FPS is just dropping over time for some reason and then the problem in this thread becomes relevant.
Is this on wayland? If it is, it is a different issue from my initial post.
It was actually my aio cooler breaking lol
I keep seeing this with current Steam, using Proton Experimental. Enshrouded and Satisfactory in particular.
If I set my mouse (Logitech G600, so 'singing-gundi' in ratbagctl, which is what I use to configure it in Linux) report rate higher than 200Hz I get building lag as I move the mouse around, this can definitely accumulate to several seconds worth.
At 200Hz it's OK unless something else is being demanding enough on CPU. The last time that was an issue was a YouTube 60Hz video playing in a Firefox tab on my other monitor.
It feels like the mouse events get queued up and only cleared at the rate the game/wine ends up consuming them. Is there no way that wine could consume them in real time, remember the latest, and only report that when a 'client' asks ? At least as an option ? The user gets what they ask for if they then move their mouse around very quickly and the game only sees very jerky movement, but it would still be better than inflicting the lag on yourself.
Replying to https://github.com/ValveSoftware/Proton/issues/4571#issuecomment-2424207630
What do your CPU temps look like? It turned out mine was a bad cooler and thermal throttling
What do your CPU temps look like? It turned out mine was a bad cooler and thermal throttling
They're fine. I'm in-game in Satisfactory, 100+ FPS according to mangohud, working fine at 200Hz, but any higher report rate and I get the lag.
CPU is holding a little below 70 degC, with the frequency holding above 5300MHz, so not at all throttled. This only happens if the mouse report rate is 'too high'. I can only set it to certain values, 125 142 166 200 250 333 500 1000, and anything over 200 and it gets worse the higher I've set it.
Whilst it's lagging, due to 'too high' rate, I note that Xorg process is pegged at 100%, especially if I try 1000Hz, which can cause the whole game to lag up severely. At 333Hz there's notable lag, and a bit of an FPS drop (from ~110 to ~90).
-------------------------------------------------------------
Command: cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
-------------------------------------------------------------
Command: lspci -tv
-[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 14d8
+-00.2 Advanced Micro Devices, Inc. [AMD] Device 14d9
+-01.0 Advanced Micro Devices, Inc. [AMD] Device 14da
+-01.1-[01]--+-00.0 NVIDIA Corporation GA102 [GeForce RTX 3080 Lite Hash Rate]
| \-00.1 NVIDIA Corporation GA102 High Definition Audio Controller
+-02.0 Advanced Micro Devices, Inc. [AMD] Device 14da
+-02.1-[02-16]----00.0-[03-16]--+-00.0-[04]--
| +-04.0-[05]--
| +-05.0-[06]--
| +-06.0-[07]--
| +-07.0-[08]--
| +-08.0-[09-14]----00.0-[0a-14]--+-00.0-[0b]--
| | +-01.0-[0c]--
| | +-02.0-[0d]--
| | +-03.0-[0e]----00.0 Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller
| | +-04.0-[0f]--
| | +-08.0-[10]--
| | +-0a.0-[11]--
| | +-0b.0-[12]--
| | +-0c.0-[13]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset USB 3.2 Controller
| | \-0d.0-[14]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset SATA Controller
| +-0c.0-[15]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset USB 3.2 Controller
| \-0d.0-[16]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset SATA Controller
+-02.2-[17]----00.0 Samsung Electronics Co Ltd NVMe SSD Controller S4LV008[Pascal]
+-03.0 Advanced Micro Devices, Inc. [AMD] Device 14da
+-04.0 Advanced Micro Devices, Inc. [AMD] Device 14da
+-08.0 Advanced Micro Devices, Inc. [AMD] Device 14da
+-08.1-[18]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Raphael
| +-00.1 Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller
| +-00.2 Advanced Micro Devices, Inc. [AMD] VanGogh PSP/CCP
| +-00.3 Advanced Micro Devices, Inc. [AMD] Device 15b6
| +-00.4 Advanced Micro Devices, Inc. [AMD] Device 15b7
| \-00.6 Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller
+-08.3-[19]----00.0 Advanced Micro Devices, Inc. [AMD] Device 15b8
+-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
+-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
+-18.0 Advanced Micro Devices, Inc. [AMD] Device 14e0
+-18.1 Advanced Micro Devices, Inc. [AMD] Device 14e1
+-18.2 Advanced Micro Devices, Inc. [AMD] Device 14e2
+-18.3 Advanced Micro Devices, Inc. [AMD] Device 14e3
+-18.4 Advanced Micro Devices, Inc. [AMD] Device 14e4
+-18.5 Advanced Micro Devices, Inc. [AMD] Device 14e5
+-18.6 Advanced Micro Devices, Inc. [AMD] Device 14e6
\-18.7 Advanced Micro Devices, Inc. [AMD] Device 14e7
-------------------------------------------------------------
Command: lsusb -t
/: Bus 10.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/0p, 5000M
/: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 1: Dev 2, If 2, Class=Chip/SmartCard, Driver=, 12M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 12: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 12: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/1p, 5000M
|__ Port 5: Dev 3, If 0, Class=Hub, Driver=hub/2p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 1: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 1: Dev 5, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 1: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 4: Dev 7, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 5: Dev 4, If 0, Class=Hub, Driver=hub/2p, 480M
|__ Port 1: Dev 6, If 0, Class=, Driver=, 12M
-------------------------------------------------------------
Command: coredumpctl -r --since -10d
-------------------------------------------------------------
Command: wpctl status
PipeWire 'pipewire-0' [1.2.5, athan@emilia, cookie:411949602]
└─ Clients:
33. pipewire [1.2.5, athan@emilia, pid:6152]
35. WirePlumber [1.2.5, athan@emilia, pid:6151]
36. WirePlumber [export] [1.2.5, athan@emilia, pid:6151]
41. fluidsynth [1.2.5, athan@emilia, pid:7464]
61. xdg-desktop-portal [1.2.5, athan@emilia, pid:6835]
64. ALSA plug-in [fluidsynth] [1.2.5, athan@emilia, pid:7464]
71. Signal Calling [1.2.5, athan@emilia, pid:146383]
74. speech-dispatcher-dummy [1.2.5, athan@emilia, pid:149860]
75. Steam [1.2.5, athan@emilia, pid:148963]
78. Steam Voice Settings [1.2.5, athan@emilia, pid:148963]
79. Firefox [1.2.5, athan@emilia, pid:146559]
89. Firefox [1.2.5, athan@emilia, pid:146559]
90. Chromium input [1.2.5, athan@emilia, pid:179453]
91. FactoryGameSteam [1.2.5, athan@emilia, pid:179981]
102. wpctl [1.2.5, athan@emilia, pid:181981]
Audio
├─ Devices:
│ 46. GA102 High Definition Audio Controller [alsa]
│ 47. C920 PRO HD Webcam [alsa]
│ 48. Rembrandt Radeon High Definition Audio Controller [alsa]
│ 49. Family 17h/19h HD Audio Controller [alsa]
│
├─ Sinks:
│ * 58. Family 17h/19h HD Audio Controller Analog Stereo [vol: 1.00]
│
├─ Sink endpoints:
│
├─ Sources:
│ 59. Family 17h/19h HD Audio Controller Analog Stereo [vol: 1.00]
│
├─ Source endpoints:
│
└─ Streams:
66. ALSA plug-in [fluidsynth]
65. output_FL > ALC897 Analog:playback_FL [active]
69. output_FR > ALC897 Analog:playback_FR [active]
73. speech-dispatcher-dummy
80. output_FR > ALC897 Analog:playback_FR [paused]
83. output_FL > ALC897 Analog:playback_FL [paused]
77. Firefox
70. output_FL > ALC897 Analog:playback_FL [active]
82. output_FR > ALC897 Analog:playback_FR [active]
85. Firefox
84. output_FR > ALC897 Analog:playback_FR [paused]
87. output_FL > ALC897 Analog:playback_FL [paused]
92. FactoryGameSteam
93. output_FR > ALC897 Analog:playback_FR [active]
97. output_FL > ALC897 Analog:playback_FL [active]
98. FactoryGameSteam
94. output_FL > ALC897 Analog:playback_FL [active]
99. output_FR > ALC897 Analog:playback_FR [active]
Video
├─ Devices:
│ 43. HD Pro Webcam C920 [v4l2]
│ 44. HD Pro Webcam C920 [v4l2]
│ 45. HD Pro Webcam C920 [libcamera]
│
├─ Sinks:
│
├─ Sink endpoints:
│
├─ Sources:
│ * 50. HD Pro Webcam C920 (V4L2)
│ 52. HD Pro Webcam C920
│
├─ Source endpoints:
│
└─ Streams:
Settings
└─ Default Configured Node Names:
0. Audio/Sink alsa_output.pci-0000_18_00.6.analog-stereo
Computer Information:
Manufacturer: ASRock
Model: X670E PG Lightning
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 7 7700X 8-Core Processor
CPU Family: 0x19
CPU Model: 0x61
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 5573 MHz
16 logical processors
8 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Supported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Supported
AVX512VNNI: Supported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Operating System Version:
Debian GNU/Linux 12 (bookworm) (64 bit)
Kernel Name: Linux
Kernel Version: 6.11.4-athan
X Server Vendor: The X.Org Foundation
X Server Release: 12101007
X Window Manager: FVWM3
Steam Runtime Version: steam-runtime_0.20240806.97925
Video Card:
Driver: NVIDIA Corporation NVIDIA GeForce RTX 3080/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 560.35.03
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 143 Hz
VendorID: 0x10de
DeviceID: 0x2216
Revision Not Detected
Number of Monitors: 2
Number of Logical Video Cards: 2
Primary Display Resolution: 2560 x 1440
Desktop Resolution: 5120 x 1440
Primary Display Size: 23.54" x 13.23" (26.97" diag), 59.8cm x 33.6cm (68.5cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 10240 MB
Supported MSAA Modes: 2x 4x 8x 16x
Sound card:
Audio device: USB Mixer
Memory:
RAM: 31174 Mb
VR Hardware:
VR Headset: None detected
Miscellaneous:
UI Language: English
LANG: en_GB.UTF-8
Total Hard Disk Space Available: 301804 MB
Largest Free Hard Disk Block: 51190 MB
Storage:
Number of SSDs: 4
SSD sizes: 2000G,2000G,1000G,256G
Number of HDDs: 0
Number of removable drives: 0
i think there are multiple different issues going on in this thread, but for me the keys not releasing problem was solved by disabling key repeat in accessibility settings as described by this reddit user. Note that this is really annoying when not gaming, so if there is a way to make proton not affected by this setting it would be really good.
These are my input driver patches I added to Proton:
Did you have any success with upstreaming these patches @kakra?
I've looked over the codebases 6 years later and I couldn't find any references in Proton, Proton-GE nor WINE for prioritizing I/O input which is a rather wasted opportunity for minimizing fluctuations in responsiveness 🙁
Did you have any success with upstreaming these patches
They have been rejected by upstream. They see no need in raising the priority, and it's probably true if your system is not overwhelmed with the game already. kwin_wayland already raises priority of the input thread, so Proton should be able to pick them up as early as possible. I haven't looked again into these patches since. After upgrading my system, the problem is essentially gone.
I usually experience vast input lag only in some games like Elite Dangerous if in-game vsync is enabled: The mouse pointer lags behind like 100ms. Disabling vsync in-game and using mangohud to limit the frame rate instead works, and there's no tearing when using wayland or xorg with forced composition pipeline in NVIDIA.
I'm not even sure if prioritizing the input threads would reliably fix the issues. Wine/Proton devs rather need to look into why games experience (exceptionally) late input under CPU load, or when using vsync (as with Elite Dangerous). There may be threads locking each other which should rather run independent from each other.
It's probably more an architectural issue that is going to be long and difficult to fix than a problem of thread priority. Mouse input in particular is received on the individual window threads, and sent back and forth wineserver. This is very inefficient, but input needs to go through wineserver at some point. We've been continuously working on fixing and optimizing things on that path but it is still not nearly resolved.
Gamepad input is even worse in the sense that it involves many wineserver roundtrips to implement the NT device IO that is required for HID devices to work properly. There is a huge room for improvement there, but it's also not clear how (or if?) it could be done.
Then at least running wineserver with raised priority (maybe?) can improve things (with the basic problem still existing).
I'm essentially using this snippet in my rungame %command% wrapper since years:
#!/bin/bash
### some stuff here
function wineserver_prio {
for second in $(seq 1 30); do
echo "GAMEMODE: Waiting for wineserver... (${second}s)" >>/tmp/gamemode.log
sleep 1
wspid=$(pgrep wineserver)
[ "${wspid}" -gt 0 ] && { schedtool -n -20 -F -p 80 ${wspid}; exit; }
done
echo "GAMEMODE: Timeout waiting for wineserver..." >>/tmp/gamemode.log
}
wineserver_prio &
### some more stuff here
ionice -n0 -p$$
exec "$@"
It waits for the wineserver to appear in the background, then raises its priority. I never looked back how it would work without this. Maybe worth a try. I think at some point in Proton history, there was a patch which would do the same from inside wineserver but it seems gone (it came from wine-staging).
I think at some point in Proton history, there was a patch which would do the same from inside wineserver but it seems gone (it came from wine-staging).
Came across this in WINE: STAGING_RT_PRIORITY_SERVER=90 STAGING_RT_PRIORITY_BASE=90
https://gitlab.winehq.org/wine/wine-staging/-/wikis/Configuration/Environment-Variables#realtime-priorities
kwin_wayland already raises priority of the input thread
How would you prioritize input thread when using some other Wayland compositors like Sway or Jay though?
How would you prioritize input thread when using some other Wayland compositors
I think all of them do this. There should be a capability set in the binary:
# getcap $(which kwin_wayland)
/usr/bin/kwin_wayland cap_sys_nice=ep
Before blindly setting it, check if the compositor is actually made to handle this properly. Usually, it's the package manager which should set this during installation, so maybe ask your distribution. Don't do this for Xorg window managers, tho! It won't work that way and has unwanted side effects (the input thread lives in the Xorg server instead).
Came across this in WINE
Proton already allows that for wine application (you don't need STAGING_RT_PRIORITY_BASE and should not use it but you need to allow your user to use higher nice and priority settings), but I think it dropped the wineserver priority patch.
Allowing games to set their thread priorities can improve things, so it's essential to allow that:
# cat /etc/security/limits.d/99-games.conf
@games - rtprio 90
@games - nice -20
This will permit users in the games group to use higher priorites. Instead of @games you can also use any other group or your user name (without @).
Came across this issue for multiple games and can corroborate the situations with high cpu usage, but i found some interesting findings:
Tested this on Hades, but it also happens on Hollow Knight when ran through proton. This doesn't happen on HK's native linux build, so this rules proton as the sole cause.
Replying to https://github.com/ValveSoftware/Proton/issues/4571#issuecomment-3358760904
I'm having this same issue while trying to run The Witness and Need for Speed: Most Wanted Black Edition using Proton Hotfix. Mouse and keyboard input seems normal, but using a gamepad exhibits this behavior. I haven't noticed this on other games though. I've tried Guilty Gear Xrd Sign, Silksong and Iconoclasts.
I would guess that this is related to Wine because this issue is a lot worse if I'm running The Witness through Wine.
I managed to find a work around for my case.
I'm using an 8bitdo Ultimate 2C and it comes with a USB dongle but also supports Bluetooth. Bluetooth gave me problems in the past so I mostly use the dongle.
Looking at the specs for this controller, it said that the USB dongle supports a 1000 hz polling rate and the Bluetooth is limited to 250 hz. While searching for fixes online I saw a mention about Wine/Proton not handling high polling rate devices well, so I decided to try the Bluetooth connection. This seems to have fixed my issue.
Theoretically, there is no such thing as "polling" in the Linux Input system. The input state in the kernel is updated at the rate which the device sends. Applications cannot really poll the device, they'll listen to an event that the state has been updated. If wine implements polling, then this means games will only poll from the buffered state, not from the current hardware state.
Looking at how GIP and Bluetooth HID protocols are implemented (I'm the maintainer of xpadneo), there isn't even a way to ask the device for its state. Xbox-compatible controllers usually report events at a rate of around 100-120 Hz via Bluetooth HID. Standard USB GIP seems to work at a similar rate, GIP doesn't have commands to poll data from the input device, it only ever reports it to the OS. Judging from experiments (and reverse engineering the USB GIP protocol with wireshark), the reporting rate in GIP seems to be around 100-120 Hz, too. The Windows driver artificially limits rumble reports from the OS to the device to 100 Hz according to our tests, which supports our observations of reporting rates. Sending rumble reports at a higher rate even crashes most genuine Microsoft firmwares, other vendors seems more robust.
However, it might be true that 8bitdo supports higher reporting rates, there's an app https://github.com/cakama3a/Polling to actually test this by moving the sticks around as fast as you can and measure how many input reports come in per second, it even measures the real resolution of the sticks. It would be interesting if 8bitdo really implements such a high "polling" rate (where it actually never would be polling but reporting rate instead). Some people overclock the USB to get higher reporting rates.
Your observation looks more like there may be race conditions somewhere in the whole stack. Given that I sometimes observe double-inputs in games (e.g., I click once with the mouse but two clicks are registered by the game), and lately I'm seeing the same behavior in kwin-wayland, I think that there's a racing bug somewhere in the input stack: At least one in kwin, and another somewhere in Proton/wine which already exists for some longer time. This also supports your observations ("I would guess that this is related to Wine...").
To my knowledge, the Linux input layer naturally implements de-bouncing, so I cannot currently blame bouncing buttons for the issue.
proton hotfixx1 2026-03proton experimentalx2 2024-10
Using latest Proton (probably started with experimental-wine-5.13-20210120 or experimental-wine-5.13-20210115), multiple games see input event loss or extreme lag.
Usually, single button presses on the gamepad aren't recognized, pressing it a second or third time and it works.
Sometimes, button presses are detected but the release isn't detected.
Axes sometimes do not update and just hang in some position until the situation eventually recovers after some time.
Button presses sometimes lag behind (usually just a short period, sometimes seconds). Axes also lag behind, often releasing an axis lags behind several seconds (see above).
In some games, this can also be observed for keyboard events. Mouse movement seems not to be affected but mouse buttons are. I usually do not play with mouse so I cannot really confirm this.
Games tested and affected:
The problem is probably depending on CPU usage of the game, titles putting more pressure on the CPU experience the problem more intense. From a programmer perspective, I'd say that the scheduler is starving the input event threads in wine. This MAY be a result from using the MuQSS scheduler in my kernel but even if it is, this is a problem that should be fixed in wine as scheduler behavior tends to change over time or due to pressure put on the system.