[RFC PATCH 4/6] user32: Remove __wine_send_input function.

[Rémi Bernon]

On 11/12/19 10:04 AM, Alexandre Julliard wrote:
> Rémi Bernon <rbernon at codeweavers.com> writes:
> 
>> __wine_send_input was introduced at a time when SendInput was handled
>> in the graphics drivers, we don't do that anymore and it makes little
>> sense to go through user32 for user input now.
>>
>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>> ---
>>
>> Notes:
>>      Making the request directly also bypasses the wait for the reply,
>>      as well as some state update, but I think it should be alright as
>>      we should not care about native vs injected input processing order.
>>      
>>      I'm not entirely sure of the implication of not waiting for the
>>      reply, but I think graphics drivers don't care about it. It also has
>>      a beneficial impact on performance in the case where we would have
>>      waited for the reply on each input.
> 
> The wait is necessary for hook processing. The state update is also
> needed to avoid redundant server calls. It doesn't look like this series
> is going in the right direction.
> 

Regarding the hooks, I assumed that if we are processing input events, 
it means that the current thread is already in a message processing 
loop, so the hooks would eventually be processed if they belong to the 
same thread. Although maybe that would depend on the message filters?

If they belong to another thread, it means that if for any reason that 
thread is not processing its messages, input events coming from the user 
would block the message loop instead of just being queued to the hooking 
thread. Maybe it's also something we expect?

Anyway, thanks for the comment, I'll drop this.
-- 
Rémi Bernon <rbernon at codeweavers.com>