After 25167fb286 get_primary_monitor_rect()
returns an empty rectangle before X11DRV_DisplayDevices_Init() is called.
So use get_host_primary_monitor_rect() to get the current X desktop size.
It's also more intuitive this way.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
After 25167fb286, get_primary_monitor_rect(),
which is used in is_window_rect_fullscreen(), may return the primary
screen size set by the last explorer instance if wineserver didn't
fully shuts down. Also get_primary_monitor_rect() no longer reports the
host primary monitor rect before virtual desktop initialization now.
So move the desktop fullscreen check after desktop initialization
so that primary screen size is updated and valid.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
After 25167fb286, get_primary_monitor_rect()
maybe invalid before display device initialization or returns the desktop
rectangle after desktop initialization in virtual desktop mode, which is
wrong. The desktop size limit should come from host system.
This fixes a regression from efbbe66669.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47815
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If we want to query host monitor dimensions, we need to use XRandR
or Xinerama handler. However when in virtual desktop mode, its display
device handler overrides other handlers. So we need to separate them.
Then we can implement features that require host monitor dimensions like
checking whether the virtual desktop window is fullscreen.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The window created in the separate thread in test_Input_mouse sometimes
fails to catch the mouse input in time. Waiting and flushing the initial
messages seems to make the issue harder to reproduce.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Be more explicit about what applies only to non-global code.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If it's an implicit this, we can handle that in interp_me.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a bug where some verions of mingw and probably gcc
assume that the result of pointer subtraction will be non-NULL,
causing MSI_OpenDatabaseW to break when given the mode
MSIDBOPEN_READONLY + MSIDBOPEN_PATCHFILE.
Signed-off-by: Vincent Povirk <vincent@codeweavers.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For some reason, on fvwm2 sometimes focus_window will be restored and activated
between the subsequent call to SetForegroundWindow() and the next call to
ShowWindow(SW_RESTORE), causing the next test to fail. Flushing first seems to
reliably work around this.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
llvmpipe is extraordinarily slow to execute glBeginQuery() [as much as 10ms per
call] when the regression test for bug 45932 is run after the previous test
drawing a 33-bit number of samples. Swap the two tests to work around this.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This reverts commit d10f2c0723.
The bug we were working around has been fixed in upstream Mono and
in Wine Mono 4.9.4.
Signed-off-by: Vincent Povirk <vincent@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
PHIDP_PREPARSED_DATA is supposed to be an opaque pointer, but the size
is accessible through user32.GetRawInputDeviceInfo(RIDI_PREPARSEDDATA),
so we will need to know the struct layout in user32, too.
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
LLVM's libunwind uses EnumProcessModules for locating .eh_frame
sections when unwinding dwarf exceptions (used on i686).
When running wine in docker (without adding custom additional
permissions), EnumProcessModules currently fails as it uses
ReadProcessMemory, which requires the SYS_PTRACE capability.
The current implementation also is slower than necessary (by a
couple orders of magnituide), for accessing the current process.
Currently, unwinding 10000 exception throws with libunwind on i686
takes 24 seconds when run in wine, while it runs in less than 0.1
second with this patch.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zhiyi Zhang