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

[Rémi Bernon]

On 11/4/19 11:22 PM, Zebediah Figura wrote:
> On 11/4/19 3:54 PM, Rémi Bernon wrote:
>> 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.
> 
> Well, maybe? It's not immediately clear to me that the scope really is 
> that big.
> 
> Setting aside for a moment the problem of whether or not to ignore 
> transformations done by the window manager, how much work would it 
> actually be to do? We're already passing mostly or even entirely correct 
> values in WM_INPUT messages, even if we're not sending them at the right 
> times. I'm probably forgetting things, but the only significant thing 
> left that I see is judging which windows to send raw input to. (Does 
> Xinput2 alone give us enough information to accurately determine that?)

Maybe not huge then, but clearly a larger change than these few patches. 
We could work towards it and these patches are be a first step, at least 
by providing a way for drivers to send raw input only.

> 
> I think as long as we're contemplating moving in this direction, we 
> really should get a good idea of what the design would look like (and 
> whether it would indeed 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.
> 
> I can understand that when raw and WM input is sent differs. I'm still 
> less than sanguine about why that needs to be a concern for us with 
> respect to how we send it, i.e. why we even need to take raw input from 
> Xinput2 in the first place. Notably, I don't think it's ever been fully 
> established why bug 45882 is really a bug and worth fixing—I mean, sure, 
> it mirrors Windows behaviour and is thus more correct in some sense, but:
> 
> (a) why would this cause problems for the applications mentioned, if 
> indeed it does?
> 
> (b) do similar native X11 applications also bypass transformations that 
> the WM performs, and, if not, are we going to cause a confusing 
> difference in behaviour by doing so ourselves? Put more simply, if the 
> user has e.g. a constant acceleration applied to their mouse at the WM 
> level, don't they expect managed windows to respect that? Ultimately 
> "behave like the application on Windows" and "behave like other 
> applications on X11" are potentially acting at cross purposes here, and 
> I'm not claiming that either one is more salient, but I want to make 
> sure this is at least considered before being thrown away.
> 

It's not very much about the raw values, and as you could see in these 
patches I'm still using "transformed" values from XInput2. But more 
about the reliability of the data source.

Because games are very often messing with cursor confining windows, the 
basic mouse motion messages are plagued with events caused by warps when 
confining is enabled -and we try to ignore these- and it also doesn't 
provide reliable movement information -that still expected by the games- 
when the cursor is moving against the confining borders.

Wine enables XInput2 when the cursor is confined to address these, and 
tries to make it coherent with basic messages, but when some games 
continuously enable/disable cursor confining it then creates another set 
of issues.

Regarding (b), it clearly would be a problem if Wine implements its own 
cursor speed and acceleration and generate cursor positions different 
from the native one.

Applications can use raw values natively and I think native games 
already do for the same reason as on Windows -to have their own internal 
mouse speed for example- and libraries like SDL use these events to 
provide relative mouse mouvement. They would behave the same as on 
Windows and in general it is only to control a camera rotation speed, 
not a visible cursor that would feel indeed weird.

>>
>>>               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.
> 
> Understandable. My intuition, though, is to make the interface more like 
> the ideal case—which, as far as I can tell, is "with full raw input 
> support". It's also to make the server agnostic as to the details of how 
> messages are produced—i.e. the server shouldn't care about whether we're 
> producing both messages from one source, or from different sources, and 
> along those lines it makes more sense to have only one way to send that 
> information to the server.
> 
> But that's only my intuition as to what Alexandre wants. As always, I 
> invite comments from the upstream maintainer.
> 
>>
>>> ἔρρωσο,
>>> Zeb-- 
>> Rémi Bernon <rbernon at codeweavers.com>
>>
> 
> -- 
Rémi Bernon <rbernon at codeweavers.com>