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@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.