On 8/26/19 6:15 PM, Derek Lesho wrote:
Remi,
I like this idea, as it would also reduce wineserver load for raw-input events, since the input should be the same regardless of which x11 thread it comes from.
After doing some digging it looks like the wineserver is only capable of providing raw input that was sent from a thread within the same process, but that could be a single dedicated thread that will only register and process raw events.
I'm not sure if it's a good thing or not, ie: is it better to have a global input source for all wine processes and windows, or is it better that each process is its own input source - and for some parts like low-level hooks, an input source for other processes. For example I don't really know what would happen if multiple processes using different X servers share the same wineserver.
Otherwise, it would require some modifications to the wineserver so that raw input messages can be broadcast to other processes.
One issue I can think of however is that we'll have to accumulate raw-input mouse events in wineserver, as in my testing when you send WM_INPUT at a rate faster than the thread calls MsgWaitForMultipleObjects, it causes some very strange behavior, at-least in over-watch.
Noted I'll keep that in mind.
Also, does dinput really send input at all times, regardless of focus? That sounds unnecessary for games.
DInput doesn't send anything but you can read the state whenever you want (and get some history buffer if configured), although it doesn't allow to read the device state in background unless explicitly requested.
AFAICS it still keeps its internal state up to date (especially in the case I'm trying to solve, w.r.t. key presses while in background).