[PATCH resend 1/9] server: Add send_hardware_message flags for rawinput translation.

[Rémi Bernon]

On 11/4/19 9:43 PM, Zebediah Figura wrote:
> Hello Rémi,
> 
> On 11/4/19 6:17 AM, Rémi Bernon wrote:
>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>> ---
>>   server/protocol.def |  2 ++
>>   server/queue.c      | 20 ++++++++++++++------
>>   2 files changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/server/protocol.def b/server/protocol.def
>> index 6af0ae0cff8..ab3af90545b 100644
>> --- a/server/protocol.def
>> +++ b/server/protocol.def
>> @@ -2315,6 +2315,8 @@ enum message_type
>>       VARARG(keystate,bytes);    /* global state array for all the 
>> keys */
>>   @END
>>   #define SEND_HWMSG_INJECTED    0x01
>> +#define SEND_HWMSG_ONLY_RAW    0x02
>> +#define SEND_HWMSG_SKIP_RAW    0x04
>>   /* Get a message from the current queue */
> 
> In lieu of other feedback, I still feel like this is kind of awkward.
> 
> Supposedly (though in practice I still don't see why this needs to be 
> true) raw input and window-message input should be sending two different 
> sets of data.

 From my understanding, raw input could be sufficient on its own for all 
input events, and wine could implement the translation to filtered and 
accelerated input from it, providing the raw values to the subsystems 
which use it directly - such as rawinput and dinput on top of it. 
However this is a huge amount of work.

In the meantime we have to deal with the native interfaces that provide 
the data, and I don't think they can be reconciliated safely as a 
uniform source.

The transformed input in X11 comes in absolute position, is already 
filtered by window, but may not be sent if the cursor is confined and 
may be the result of some X11 requests, without any user action. The raw 
input comes from XInput2 in relative or absolute mode depending on many 
things, but is guaranteed to always come from the devices. And ofc 
there's no ordering guarantee between the two.

>               If that's the case, it feels more sensible to me to 
> actually split them into two separate calls to __wine_send_input() in 
> every case, not just when we actually have native raw input support. 
> That is, "no native raw input support" is where we have to work around 
> an insufficiency in the lower level, and we should design the code 
> around the "correct" case.
>
> I don't know what the actual performance penalty of making two separate 
> wineserver calls is, or whether it's worth caring about for systems that 
> don't support the Xinput extension.
> 
> If nothing else, I'd suggest to change these flags to something more 
> like SEND_HWMSG_WINDOW and SEND_HWMSG_RAW, and then use the combination 
> of both in the cases where we have only one source of input.

I'm fine with that. I was mostly trying to minimize the changes for the 
other drivers and the "non raw input support" case.

> ἔρρωσο,
> Zeb-- 
Rémi Bernon <rbernon at codeweavers.com>