Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51599

Use INTERNET_LoadProxySettings when settings from registry are needed.

Valuator names aren't well specified, and although they are usually
named "Rel X/Y" or "Abs X/Y", there are cases where the names are
different.

Lets just assume that the first two valuators are the X/Y axes, as it
seems to be generally the case.

This is the required version for XInput2 touch events. It also allows
to greatly simplify the code by listening to master device events only
and get rid of device id tracking:

Under XInput2 protocol version < 2.1, RawEvents are not supposed to be
sent if a pointer grab is active. However slave device events are still
received regardless of this specification and Wine implemented a
workaround to receive RawEvents during pointer grabs by listening to
these slave device events.

By advertising the support of XInput2 version >= 2.1, where RawEvents
are sent even during pointer grabs, we ensure to receive the RawMotion
even if a mouse grab is active.

Fixes a regression introduced by 229b4561,
which caused the icons to not be visible initially in the virtual desktop
systray.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Fixes a regression introduced by 62c6646d,
because SetParent will unconditionally activate the window, causing newly
added icons to deactivate the foreground window.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

This should fix test failures on Windows.

Appending the entire RAWMOUSE / RAWKEYBOARD / RAWHID + report structs
after the hardware message data, instead of using a custom intermediate
structure.

This gives a 30% performance increase in a local test with a very large document.

Stream sink such as evr can't be prerolled a second time, and when we are
restarting from a paused state, those stream sink will already be prerolled
so don't preroll them again. Otherwise we will be waiting for Prerolled
events that will never come.

Most paths that hold both the display_lock and the display_devices_init
mutex acquire them in the order just mentioned. However, there are two
cases where these are acquired in the opposite order, which with
unfortunate thread interactions and timings can lead to a deadlock. Fix
these cases to use the same order as the rest of the code.