Input latency

[duud]

Current input implementation has a high latency as compared to windows - which makes (e.g. first-person shooters) unplayable. A hacky test implementation using evdev (/dev/input) + eliminating unnecessary context switches (X11 -> wineserver -> client) yields very low latency input. It also results in more precise (mouse)-input when using relative events as compared to using X11 event data. Pls consider a low latency input implementation for proton.

[kakra]

Would you mind to post that hacky patch so it could be improved by the community?

[duud]

Ofc: https://pastebin.com/713vKx7x

Don't forget it's hacky, not general and incomplete. It implements a subset of the interface needed for Quake Champions.

[kakra]

Thanks, I've stored it in my download folder for now, will look into it later. Maybe I'm reaching back to for further questions if that's okay.

[jqadev]

Any update on this patch? Maybe you should create a PR here.

[jqadev]

@aeikum is this patch no more needed? Imho it is very important change but almost no one is interested in it.

[kakra]

@jqadev This is not a patch, it's a single file. I'm not sure if there's even an input driver in Wine/Proton already which opens the Linux HID devices directly (/dev/hidraw* or /dev/input/event*) instead of going through the event layer, and if, I don't know how to use it for games. But the only way I can think of would be open those devices directly from within the Wine code to reduce input lag.

[tyrohellion]

Hi, is there any update on this? I am super confused where to put this file. Do I create a folder for /dev/input/event and put the file in there? Or maybe this solution is no longer needed?

[kakra]

I'm not sure if this is still needed: Proton supports using hidraw devices now and uses SDL2 for this: Input data can be read directly from the hidraw device in wine by utilizing SDL2's capabilities, transform it into xinput data, and pass it to the wine driver. Of course, this is for joystick/controller devices only. And it needs proper permissions to the Linux hidraw device node.

I'm not sure if Proton will use something similar for mouse/keyboard input but if does use SDL2 for this, it should implement generally the same idea as the prototype file linked above.

@tyrohellion You cannot put the file somewhere. It's a source code file and needs to be replaced in the wine source code. But this file is vastly outdated and probably won't work anymore anyways. Also, it hard-codes some device paths. It's just a prototype idea. This probably needs to be reconsidered by the original author.

[tyrohellion]

I'm not sure if this is still needed: Proton supports using hidraw devices now and uses SDL2 for this: Input data can be read directly from the hidraw device in wine by utilizing SDL2's capabilities, transform it into xinput data, and pass it to the wine driver. Of course, this is for joystick/controller devices only. And it needs proper permissions to the Linux hidraw device node.

I'm not sure if Proton will use something similar for mouse/keyboard input but if does use SDL2 for this, it should implement generally the same idea as the prototype file linked above.

@tyrohellion You cannot put the file somewhere. It's a source code file and needs to be replaced in the wine source code. But this file is vastly outdated and probably won't work anymore anyways. Also, it hard-codes some device paths. It's just a prototype idea. This probably needs to be reconsidered by the original author.

Gotcha, thanks for the reply btw

[Jordan-Jay]

I will follow up the issue in more detail possibly to what this person may or may not was experiencing. This is at least for me anyway on multiple hardware configurations was replicable and was experienced with multiple different wine programs inside of a Linux environment. Mouse Input Delay (Specifically Mouse's Button Delay) was experience in all applications i tried which majorly rely on click timings. I noticed a drastic difference in both how long the program took to respond to my mouse click and my mouse button release. This information alone might not be a lot to work off of since i didn't time my results to the ms per mouse input. I think the delay is significant enough that it should be noticeable to most users. Due to very little posts or mentions about this issue at all it makes me think this is possibly hardware based or external software issues. Although i'm not sure and i'm not confident on that being the issue as I've tried different GPU and CPU branding with Linux. To not avail fixing this issue. It seems to be mouse only as Keyboard has no delay and is identical to windows in all aspects. Seems to be the way the mouse is being processed through wine to the desktop and back? Not sure honestly. I have yet to test my findings on Mac OS although in brief stints in the past there might be delay there also. Tested programs, OSU! and Geometry Dash. As well as windows input latency checkers along with cross checking native input in Linux to be sure this was wine specific and it seems to be.