As a fallback implementation, using English keyboard layout.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
At least on recent Windows, the HKL values are a combination of user
selected UI language in the low word, and keyboard layout id in the high
word.
The keyboard layout id used in HKL is sometimes different from its name,
as returned by GetKeyboardLayoutName, in which case it's the "Layout Id"
value in the corresponding registry key under the layout name.
Signed-off-by: Rémi Bernon <rbernon@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>
Validating that SendInput with INPUT_HARDWARE type should be no-op.
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>
Since whole_rect / client_rect are updated asynchronously, there may be
a small lag between X11 and Wine regarding the expected window position.
Then, as events' x and y fields are reported relative to the X11 window
position, this lag can cause inconsistencies when we compute absolute
mouse positions.
Also, applications that control their own position while being moved
cause additional whole_rect / client_rect updates, before X11 knows
about it.
This can make applications like Winamp go nuts when they are being moved
and move all over the place "randomly".
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46309
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Calling get_input_codepage involves doing quite a lot of things, and
doing it for every message type, when it's not needed, is inefficient.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The WmShowRestoreMinimizedOverlappedSeq message sequence in tests
clearly show that there is a WM_ACTIVATE message at the end of
ShowWindow() calls after restoring a minimized window, and it's
not from SetFocus().
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47507
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It looks like that GetKeyState is supposed to catch key presses when
called from a background thread even after its thread message queue and
thread input structures have been created.
This happens in Bioshock 2 Remaster, and causes the game to stay forever
on a "Press space to continue" screen, as the thread checking for space
key press calls GetKeyState repeatedly (and PeekMessage), although it's
in background.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=26269
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some applications (e.g. Lego Worlds, Hitman 2) use (-32000,-32000) to
determine whether a window is minimized.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Even though MSDN says 0 and 1 are both valid and they represent the default refresh rate of display
hardware. Some games rely on the value being the real refresh rate and use it to cap frame rates.
Fix an issue that Sakuna: Of Rice and Ruin reports monitors of 1Hz and cap to 1fps.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular, test sending WM_CANCELMODE to a parent of the capture window.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Killing explorer breaks later tests. We can create a new desktop
without a shell instead.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48142
Signed-off-by: Esme Povirk <esme@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
WM_DEVICECHANGE's lParam can be either a pointer to a variant of
DEV_BROADCAST_HDR or an immediate value (usually 0) depending on
the wParam's value.
This fixes a crash when broadcasting WM_DEVICECHANGE with
wParam = DBT_DEVNODES_CHANGED, lParam = 0.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
get_display_dc() may be locking display_dc_section at the end of
user driver initialization in LoadCursorA() called from
register_builtin_classes(). If the driver initialization initiated
in CreateDCW() goes in parallel with the initialization started
elsewhere without holding display_dc_section, the process can deadlock.
Fixes random lockup on start in Hammerting.
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
No need to pass parameters via struct copying.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of calling SendMessage, similarly to the SW_HIDE case.
Based on a patch by Kimmo Myllyvirta <kimmo.myllyvirta@gmail.com>.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=39731
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Having a __wine_display_device_guid property in the desktop window only guarantees that the window
is created. Explorer.exe still has to finish setting up virtual desktop, display settings etc.
load_desktop_driver() needs to make sure that the desktop initialization is done before allowing
applications to call user32 driver functions. Otherwise, they might get incorrect data. This race
condition became apparent after aadae4d1ea, which adds ~100ms to the
initialization process.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49762
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This allows games like solitaire, chess titans, etc. to
use animations.
Signed-off-by: Fabian Maurer <dark.shadow4@web.de>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's already some in dinput, but this is a more appropriate location.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Although most of the older Windows versions allow changing to a 1Hz display mode, it returns failure
on Windows 10 1909+.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
EnumDisplaySettings() on Wine does not write beyond the end of DEVMODE because it doesn't use
dmDriverExtra currently, but this implementation detail should not be relied on.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zero initialize DEVMODE before passing it to EnumDisplaySettings(), which may write beyond the end
of the DEVMODE structure on Windows because the dmDriverExtra field is uninitialized.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a regression introduced by
08bf605acb.
It could lead to stack corruption because ret can be negative when the
output position, p, doesn't point the beginning of the buffer before
the inner loop.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
ERROR_INVALID_HANDLE or ERROR_INVALID_MONITOR_HANDLE is from
GetMonitorInfo(), not EnumDisplayMonitor().
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes the GetRawInputData regression introduced with
359ee2ecc2 where the message data couldn't
be read twice, while keeping the overwrite logic it introduced.
This also adds some SetLastError to fix some unit tests todos.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49522
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This flag allows applications to receive rawinput messages while in
background. They have to specify a target hwnd, which will receive them,
and the messages will carry a RIM_INPUTSINK wparam if the process wasn't
foreground.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This makes legacy mouse window messages such as WM_MOUSEMOVE and others,
to stop being sent, including to low-level hooks. The desktop mouse
state should still be udpated.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This delivers the rawinput messages to the correct process, regardless
of where the input was received.
As for now RIDEV_INPUTSINK is still not implemented, this only fixes
the case where input is injected in a background process and where it
should not receive rawinput -as in the test- or when cursor moves over
a background window and the foreground process should have received
rawinput messages.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Another thread is created to execute the tests, for SetThreadDesktop to
succeed consistently. It seems to fail spuriously if it is called from
a thread that already created some windows before.
This shows that rawinput messages may be dispatched across desktops,
but only if the subscribing process has a window in the input desktop,
and it is the foreground process (even if the target window may be in
another desktop).
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When RIM_EXINPUTSINK is used, messages are received in background
only if the foreground process didn't register for rawinput messages
itself.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rawinput messages are not received anymore if the foreground window is
from another process. Using RIDEV_INPUTSINK makes it possible to receive
them again, but with RIM_INPUTSINK flag.
When multiple processes register for rawinput messages, the foreground
process will receive the message, as well as any other that registerd
with RIM_INPUTSINK flag, including when the foreground process itself
did.
Currently the messages may be received correctly, but that depends on
where the input events are generated, so add another test case with
messages sent from the test process, and validate that nothing should
be received.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The rawinput messages are received on the target window if is from the
same process as the foreground window, it doesn't need to be the
foreground window itself, or use RIDEV_INPUTSINK.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This tests basic functionality by injecting mouse event and checking
the number of each messages received.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The default is of the form "Service-0x<luid high>-<luid low>$" where the
luid in question is the logon session luid.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
0 or 1 in dmDisplayFrequency means to use the default frequency.
Fix Disgaea PC and Ostriv failing to launch in exclusive fullscreen mode.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Set DM_POSITION and DM_DISPLAYORIENTATION when calling
EnumDisplaySettings(ENUM_REGISTRY_SETTINGS). DM_DISPLAYFIXEDOUTPUT
is not set because it is not necessarily reported according to tests.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It is currently unsupported. This helps later patches so that
settings handlers using a new interface can be introduced without
detaching adapter support, making patches smaller.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
NULL device and mode parameters mean to restore all adapters to their
registry settings. Since all user graphics drivers only support a
primary adapter now, it's okay to restore only the primary adapter.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Only the highest and lowest bits in the return values of these functions
have a meaning, the others are undefined. While the other bits are
always cleared in Windows, wine stores information there. Some programs
expect these undefined bits to be zero, though, so make sure they are
not set.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=30814
Signed-off-by: Markus Engel <markus_wine@familie-engel.online>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
According to the Extended Window Manager Hints (EWMH) spec 1.3 regarding
_NET_WM_STATE_FULLSCREEN, "the Window Manager is responsible for
restoring the original geometry after a switch from fullscreen back to
normal window.", which means that removing _NET_WM_STATE_FULLSCREEN from
a window may cause the window to receive a ConfigureNotify event to
restore the window size, thus causing a application resize action to be
overwritten by the window managers.
Fix a game called Mugsters becomes maximized after exiting full screen.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch by Micah N Gorrell.
This fixes controller hotplugging in Into the Breach.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Previously, callbacks were called with a critical section held. It was
intended that monitor handles passed to callbacks should always be valid.
But it created a deadlock condition when callbacks call other functions
which try to grab the critical section using a different thread. Tests
also show that a monitor handle can be invalid after a display change.
So do not hold the critical section when calling callbacks. Monitor
handles will be checked when passed to GetMonitorInfo(), which is the
sole function that consumes HMONITORs.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
test_ChangeDisplaySettingsEx() can generate so many posted messages
for display change events that USERPostMessageLimit is reached and
ERROR_NOT_ENOUGH_QUOTA is returned for PostMessage(). Call flush_events()
after mode changes to limit message post rate.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48586
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Halo: Spartan Strike attempts to discover input devices using rawinput. It
expects to be able to open at least one device file with a zero access mask. It
does not perform any other operations on the file.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon