On Thu Jul 9 08:34:10 2026 +0000, Rémi Bernon wrote:
I will have a closer look but it might take some time, and I'll be out for a couple of weeks as well. Fwiw this might be okay, but SDL is only one of the multiple backends we have, and we may want to have something similar elsewhere. Also I believe (but that may need to be confirmed that it's still the case) there's other performance bottlenecks in the HID device path, and if a device is pushing a high volume of events, it's probably going to impact wineserver badly anyway. This is because of our current NT device I/O, which I believe does several wineserver roundtrips for IRP processing. So my opinion is that this will cause some potential input loss, especially with quick motion, which may even happen randomly just because one read was a little bit too late for some reason, and not only under heavy load.
If we are unable to keep up with high polling rate devices we need to find exactly where the bottlenecks are and fix it there. It is not obvious to me that the SDL polling loop is the bottleneck, but if it is it will need to be measured more exactly. The whole roundtrip between the hardware / Linux, or even just between the received SDL event, and the XInput frontend includes too many intermediate and much heavier layers, like the NT device IO, for which I'm much more confident that are a source of contention / load / delay. If this polling loop is a bottleneck it can easily be measured with some QPC calls around two successive SDL_WaitEventTimeout calls. As far as I can tell here, it's in the order of a couple microseconds, so should be fast enough to cope with events coming at several kHz at least. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11318#note_149538