[PATCH v10 2/9] server: Move mouse raw-input message faking from user32 to wineserver.

[Derek Lesho]

Also, keep in mind that with the combination solution, we will only be
saving wine-server calls when the window is clipped.  Raw-Input data
is necessarily being send from many x11 threads and subsequently being
discarded if the window isn't the foreground one.  With the current
version only one extra normal hardware message is being sent per
frame, the one with the clipped window.

As outlined by Remi in a previous email, with further fixes it may
even be possible to remove this extra layer of RawMotion and use the
RAWINPUT structure for the low-level hooks that dinput uses, but I'm
not entirely sure whether that is correct yet.

On Mon, Aug 5, 2019 at 1:22 PM Derek Lesho <dereklesho52 at gmail.com> wrote:
>
> What we do now is send a win32-defined INPUT structure to
> __wine_send_input and send_hardware_message.  If we want to send raw
> data alongside it we'll have probably need to send in a RAWINPUT
> structure as well as an INPUT structure to these functions.  Most
> invocations of __wine_send_input and send_hardware_message aren't
> sending raw-input data at all, but since C doesn't have optional
> parameters we'd have to refactor all invocations of it.
>
> This also doesn't solve your primary concern, which is the static
> variable to indicate whether we want to emulate raw-input mouse
> movement.  Yes we could duplicate the raw-input emulation code into
> all the display drivers for the mouse now and the keyboard in the
> future, but the current solution completely avoids this, and allows
> display drivers that have raw-input capabilities to seamlessly send
> what they want.
>
> On Mon, Aug 5, 2019 at 12:55 PM Zebediah Figura <zfigura at codeweavers.com> wrote:
> >
> > On 8/5/19 11:25 AM, Derek Lesho wrote:
> > > Zebediah,
> > > I think that using hw_input_t for rawinput would make the code harder
> > > to follow.  To do it this way we'd probably want to transform RAWINPUT
> > > into the custom fields of hw_input_t from __wine_send_input, and
> > > decipher the result on the server side.  Using a hw_rawinput_t allows
> > > us to more closely match the internal data structures of windows from
> > > the display drivers / user32.
> > >
> >
> > I'm not sure I see how this is harder. It's the same thing we currently
> > do, except now we're adding another couple of fields for raw messages.
> > That way, we don't have to add any extra logic, we just pass more data
> > along the same paths.
> >
> > I also don't see why matching internal data structures should be a goal
> > of ours.