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

Derek Lesho dereklesho52 at gmail.com
Mon Aug 5 12:22:45 CDT 2019


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.



More information about the wine-devel mailing list