They are no longer used from PE code.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The keyboard layout matching algorithm can assign a negative score
to a keyboard layout. If the user has a strange keyboard layout,
possibly a custom one, it might happen that all keyboard layouts
known by Wine get a negative score. This is not an error in itself,
and we should still strive to find the best match.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
And send_hardware_message.
This makes it possible to use __wine_send_input to send extended input
data, such as HID device notifications and WM_INPUT messages carrying
HID reports.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50506
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The Binding of Isaac transitions in and out of fullscreen when the "F" key is
pressed. Specifically, it will swap states when receiving WM_KEYDOWN,
provided that the previous key state was not pressed (i.e. bit 30 is 0).
However, as part of the process of transitioning, it hides and shows its
window, causing it to temporarily lose focus. If the F key is released while
the window does not have focus, Wine misses this fact, and thinks that the
key was already pressed the next time it is pressed, causing the game to
refuse to change focus. Windows will not deliver WM_KEYUP messages to a
window that does not have focus, but it will always report the true previous
state of any key on the keyboard when requested.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These will not actually do anything, and were probably added by mistake,
after the similar calls to VK_CONTROL et al. above.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, some symbol keys (e.g. backslash) map differently.
As a result, jp106's scan code and vkey tables equal to macjp.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
After processing several X events, X11DRV_MsgWaitForMultipleObjects always
tells us that a new message is available. This is not true for some cases.
For instance, when we call DestroyWindow, the X queues DestroyEvent. Then,
X11DRV_MsgWaitForMultipleObjects handles the event only; none is posted or
sent as hwnd for destroyed window is unavailable. However, the function
states "new message is available" by returning count - 1 value.
This is an issue for CoWaitForMultipleHandles because it expects a new
message in the queue and consumes the message.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>