[PATCH v4 2/2] dinput: Fix DInput8 keyboard behavior for injected events with scancode=0.

[Rémi Bernon]

On 4/17/20 8:45 PM, Zebediah Figura wrote:
> 
> For what it's worth, that patch could be removed; it was a workaround 
> for an issue that I eventually had to fix another way. I figured it was 
> correct anyway, but as this issue is showing, it may not be worth having...
> 

It's actually partially fixing the issue, as without it, and because the 
game does not processes its hooks, every keyboard input has to wait for 2s.

The issue is that it only works on the user side, so only if called from 
another hook, so when no DInput hooks are used, the server directly send 
the message to the game and never removes the hook.

I implemented the server-side version of the removal, but as my testing 
didn't show that it was actually done reliably on Windows, I wasn't sure 
if it was correct.

In any case, the Windows timeout is 300ms rather than 2s, but that's 
already to long to wait for keyboard.

The actual thing to solve is probably find why the game never replies to 
its hook messages in the first place. Or maybe the hook messages are 
just queued on Windows regardless of hooks, while other subsystems 
process the input messages transparently. On Wine, as the input messages 
are sent from the winex11.drv loop, every time a hook is not responding 
the whole window freezes.
-- 
Rémi Bernon <rbernon at codeweavers.com>