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>
Double scan modes have double the dots to be scanned and interlaced
modes only have half the dots to be scanned.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some graphics drivers keep CRTCs attached to disconnected outputs.
This could cause the XRandR 1.4 display device handler to incorrectly
mark outputs as mirrored. So enumerate outputs instead of CRTCs when
finding mirroring slaves.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48932
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
GNOME implements the startup notification protocol correctly which
means it checks StartupWMClass against both WM name (res_name) and
WM class (res_class). Thus it does not need this patch.
The situation is different for desktop environments that thunk to
Wayland such as Crostini. Wayland does not have separate concepts
that WM name and WM class can be mapped to. So Crostini decided to
only use res_class resulting in it trying to match 'Wine' to the
program name stored in StartupWMClass.
While Crostini's choice is unfortunate for Wine, most other
applications (e.g. all GTK applications) already store the same value
in both WM name and class. So in the interest of compatiblity it makes
sense for Wine to do the same.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
RandR minimum screen size is not necessarily 0x0. Some drivers report
resolutions smaller than the minimum screen size. When Wine tries to
switch to these resolutions, a X error is generated and causes process
exit.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Several applications -Steam, Battle.net for instance- handle the
WM_NCCALCSIZE message to override the non-client areas size and make
the client area cover the whole window, instead of changing the styles.
In winex11.drv, in decorated mode, we adjust the window rect according
to the window style to hide the unwanted decorations behind the frame,
but when client and window rects are equals, there's nothing to hide
and the actual window styles are irrelevant and can safely be ignored.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=40930
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Calculate XReconfigureWMWindow() mask in X11DRV_resize_desktop()
instead of doing it in EnumWindows() callback update_windows_on_desktop_resize()
because the result is the same anyway.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes a regression introduced by 74efb3e872,
which caused some random pointer warping on a setup with multiple "workspaces"
when switching between them and a full screen game that warped the mouse.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Commit 71d35d8940 broke the way
WM_TAKE_FOCUS protocol is implemented: WM_MOUSEACTIVATE now replies
MA_NOACTIVATE by default when using HTCAPTION.
We use the WM_MOUSEACTIVATE -although Windows does not- regardless of
the way focus is changed to check whether a window wants focus, and
Windows sometimes changes focus regardless of the message reply.
Steam and the Wine system tray are affected for instance.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some applications pass FORMATETC.dwAspect=0 to
IDataObject_[Query]GetData() during drag and drop, which
is not a valid DVASPECT_* value. Tests show that Windows
Explorer completely ignores .dwAspect for CF_HDROP when
it is the drag source, treating all values as
DVASPECT_CONTENT instead. Do the same.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=43368
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Testing using the Wacom wintab32 (from driver version 6.3.37-3) on
Windows 10, it appears that the values for lcOut* were likely
accidentally mixed up with the values for lcSys*. The lcSys* values are,
according to the documentation, supposed to specify the extent of the
screen mapping area for the cursor, wheras lcOut* simply specifies the
output coordinate space for the given context. There is no logical
reason I'm aware of for why lcOut* would have different default values
from lcIn*, and in testing Wacom wintab32 defaults lcOut* to match
lcIn*.
In addition, lcSysExt* should use SM_C*VIRTUALSCREEN instead of
SM_C*SCREEN, to handle multi-monitor setups properly. Setting lcSysExt*
to these values works even if the tablet is mapped to a subset of this
area.
After this change, PaintTool SAI 2 appears to work out of the box. Other
wintab clients I tested appear to be unaffected (such as the Wintab SDK
demos and Adobe Photoshop CS2.)
Signed-off-by: John Chadwick <john@jchw.io>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Not all XInput events contain axes information. In particular, libinput
does not seem to provide axes information on button_event.
Signed-off-by: John Chadwick <john@jchw.io>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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>
This fixes a regression from 22795243b2,
which calls thread_init_display() and eventually XOpenIM() before
X11DRV_InitXIM() is called.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47821
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
So that a process can still get the correct virtual and primary monitor
rectangles if display devices are reinitialized in another process.
Note that we can't use EnumDisplayMonitor() and GetMonitorInfo() here
because they are not loaded when loading winex11.drv.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
XGrabServer() stops the processing of other display connections
until a XUngrabServer() call is actually processed by the X server.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
D3DKMTSetVidPnSourceOwner needs to be implemented in the graphics drivers
because we need to maintain the VidPN source ownership information list
in the graphics drivers. For example, the graphics drivers need to release the
exclusive ownership when a new window is moved to a monitor which has been taken
exclusive ownership.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some XRandR implementations, e.g., the QXL driver used on Debian 10
TestBots, don't report any providers. In this case, we can still
search in XRandR screen resources to get adapters.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These events are received on mutter, when moving undecorated managed
windows, although Wine never grabs the keyboard itself.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The virtual desktop display device handler is actually the
Xinerama handler, but with a much higher priority. So that
it will be preferred in virtual desktop mode when other display
device handlers are introduced, e.g., the XRandR handler.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, the retrieved primary desktop might be from the last explorer instance
if we launch new explorer instances before wine server fully shuts down.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If a window with an OpenGL surface attached is reparented as a child window,
and then reparented as a top-level window, so that its whole window is
destroyed and then recreated, it will be recreated with the colormap of its
child window, which more than likely has a different visual. This violates
the X11 specification, which states that a window's colormap must have the
same visual as the window itself, and causes the X server to return BadMatch
to the CreateWindow request.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the same thread repeatedly calls ClipCursor, a message window is
created for every call, then stored in x11drv_thread_data->clip_hwnd.
The WM_X11DRV_CLIP_CURSOR notification is then sent to the desktop
window, then to the previous clipping thread in order for it to destroy
its clip_hwnd. But as the clipping thread is the same, and because
x11drv_thread_data->clip_hwnd has been overwritten, it does not satisfy
the "hwnd == data->clip_hwnd" condition and the window leaked.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Frequent calls to XResetScreenSaver cause performance problems on some
GPU drivers, see https://bugs.freedesktop.org/show_bug.cgi?id=110659
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
XWarpPointer will always succeed, regardless of grabs, so if the pointer
is already grabbed, by some other application, we should not ask to warp
it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This flag should only indicate a successful call to XGrabPointer. If not
then we could assume we have ownership of the pointer when we don't.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As we ignore these NotifyGrab / NotifyUngrab w.r.t focus decisions,
some applications are unaware of mouse grabs being lost and sometimes
cursor clipping is lost. We have to keep the last clip rectangle and
restore it when grab is released.
This has been squashed with the foreground window check from
Zhiyi Zhang <zzhang@codeweavers.com> to fix an issue that happens when
switching from a fullscreen window - because there's some additional
focus events involved - but in general, if the window that is getting
focus cannot be activated:
When FocusIn/NotifyWhileGrabbed is received, SetForegroundWindow is not
called if the window cannot be activated. When the FocusIn/NotifyUngrab
event arrives for the same window, we have to check the foreground
window before restoring cursor clipping rectangle.
For reference, the event sequence when pressing Alt-Tab - for WMs that
grab the keyboard - is the following:
1. FocusOut/NotifyGrab, when WM grabs the keyboard.
2. FocusOut/NotifyWhileGrabbed, while WM switches windows, this calls
SetForegroundWindow(GetDesktopWindow()).
The event sequence for normal windows ends here, but for fullscreen
windows, there may be these additional events:
3. FocusIn/NotifyWhileGrabbed, which may not change Wine foreground
window if it cannot be activated.
4. FocusIn/NotifyUnGrab, when WM releases the keyboard while switching
windows, this is ignored but it should not retry to grab the cursor,
because window is not foreground.
5. FocusOut/NotifyNormal, when WM finishes switching the windows.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the window manager has taken a keyboard grab, it may be going to
move the window itself, so the application should not move the cursor
at the same time.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Several window managers are sending FocusOut with NotifyGrab mode
then FocusOut with NotifyWhileGrabbed mode when a window focus is lost,
as a consequence of grabbing the keyboard input before changing window
focus.
This is the case during alt-tab, but keyboard can also be grabbed when
bringing activity view or clicking on the title bar. In this cases
NotifyWhileGrabbed events aren't sent until the window really loses
foreground.
In the same manner, when focus is restored, they usually send FocusIn
with NotifyWhileGrabbed mode followed by FocusIn with NotifyUngrab mode
when the keyboard grab is released.
When bringing activity view back and forth, or clicking on the title
bar, only NotifyUngrab event will be sent.
In order to be consistent across WM and to help simplifying focus
handling, just ignore focus events related to keyboard grabs.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
So that other display device handlers such as XRandR can be introduced
because they might report a virtual screen size with different top-left
corner and the primary screen may be different as well.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Getting screen resources will be used in multiple places.
So put it in a function.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@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>
Display device handlers are used to initialize the display device
registry data. Different handlers can be implemented according to
the defined interface, for example, via Xinerama or XRandR.
With those registry data, EnumDisplayDevices, EnumDisplayMonitors
and GetMonitorInfo can be built on top of it.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Spurious errors that would otherwise be handled by ignore_error() may cause
OpenGL context creation to fail.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Prevent creating a gl_drawable for a window as type DC_GL_WINDOW if
there are known children of the window, since DC_GL_WINDOW does not
support clipping.
Recreate a gl_drawable that was previously create as type DC_GL_WINDOW
when a child is encountered.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=15232
Signed-off-by: Micah N Gorrell <mgorrell@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch by Gabriel Corona.
According to the RandR spec for RRSetCrtcConfig:
"The entire area of the CRTC must fit within the screen size, else a Match
error results. As an example, rotating the screen so that a single CRTC fills
the entire screen before and after may necessitate disabling the CRTC,
resizing the screen, then re-enabling the CRTC at the new configuration to
avoid an invalid intermediate configuration."
This patch involves resizing the screen also when shrinking a CRTC, not just
when expanding it past the current screen size. This is partially because we
have no way to reliably determine the current display width (DisplayWidth() is
never updated past opening the connection, and RandR exposes no way to
retrieve the screen dimensions), and partially because it's probably what the
user wants anyway (e.g. it's what the `xrandr` configuration app does when the
screen size is not expliticly specified).
This patch fixes TestBot failures on the Debian machines for ddraw, d3d8, and
d3d9 device tests.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33290
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch by Eriks Dobelis.
Signed-off-by: Alistair Leslie-Hughes <leslie_alistair@hotmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The failed mode error message dumps all the mode fields, that were
being tested. Change this output so that only the mode fields
explicitly being matched against are displayed. Make the failed
message use formatting consist with the trace message, earlier in this
function.
Signed-off-by: Rob Walker <bob.mt.wya@gmail.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>
The fps counter is implemented in winex11 because winevulkan thunks can
be bypassed.
Signed-off-by: Józef Kucia <jkucia@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zhiyi Zhang