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

Windows SDK skips the value 14 and KMTQAITYPE_DISPLAY_UMDRIVERNAME was assigned
a value of 71 in the SDK but wasn't in the correct order.

Since recently, unwinding never should need to look at the
unix libs any longer, and as aarch64 requires PE builds, there
should be no need to unwind through any .dll.so files any
longer.
Signed-off-by: Martin Storsjö <martin@martin.st>

And run SetCursorPos / ClipCursor tests in a separate function, they
don't need hooks or windows.

And run them in the dedicated desktop.

And rename keyboard tests to avoid conflicts with mouse tests.

This is to avoid crash in Process Explorer 17.05.

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

Building for ARM with libunwind available has been broken
since 89f3c597, due to
references to raise_func_trampoline that were left behind.

In Linux builds, libunwind isn't practically needed since
a27b202a (which implemented an
internal EHABI unwinder). That unwinder currently only supports
Linux, due to relying on dl_iterate_phdr, but if necessary, we
could also try to detect support for dl_iterate_phdr in configure
for other OSes.
Signed-off-by: Martin Storsjö <martin@martin.st>

Libunwind hasn't been necessary for unwinding through the ELF
bits since 03d4ba67.

This reduces the number of potential build configurations to
keep track of.
Signed-off-by: Martin Storsjö <martin@martin.st>

Once we've reached the condition for skipping a core, we will
skip all other cores in the same range as well - don't print
a fixme message for each of them.
Signed-off-by: Martin Storsjö <martin@martin.st>

And to ImmTranslateMessage if they have been processed.

We don't return 0xe001 high word anymore, so the tests are now failing.

It is prone to spurious failures and we don't really care about it
being precise yet.

Fixes +relay for applications that use multiple threads when running in
new Wow64.

Allows such IMEs that process keyboard input to do so. For instance,
fixes backspace and escape for handwriting methods.

Autocenter is a default effect playing on the device following power
up or reset. It is disabled by stopping all effects. On at least
some devices (all?) it is a spring effect playing in slot 1.
Capturing Windows USB packets reveals it dinput acquire does (1) a
reset (this enabled autocenter) and, if autocenter is disabled, (2)
a stop all effects (this disabled autocenter).

This logic works regardless of whether autocenter is a spring effect
playing in slot 1 or not. It does mean autocenter can only be set
when the device is not acquired. Testing on Windows reveals setting
autocenter properties while acquired returns DIERR_ACQUIRED even
if the device is exclusively acquired, so this is consistent.

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

This was broken in 78c2b7df.
Signed-off-by: Martin Storsjö <martin@martin.st>