[PATCH 0/1] MR2902: winex11.drv: Expose GWL_STYLE and GWL_EXSTYLE as X11 properties.
As _WINE_HWND_STYLE and _WINE_HWND_EXSTYLE respectively. Gamescope parses these to make smarter decisions about what window to primary focus, or to treat as a dropdown/overlay. This was originally a Proton commit by Remi Bernon, however, it would definitely be nice to have support for Gamescope focusing correctly under upstream Wine as well. Fixes a bunch of games/launchers run with Wine under Gamescope. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902
From: Rémi Bernon <rbernon(a)codeweavers.com> As _WINE_HWND_STYLE and _WINE_HWND_EXSTYLE respectively. Gamescope parses these to make smarter decisions about what window to primary focus, or to treat as a dropdown/overlay. This was originally a Proton commit by Remi Bernon, however, it would definitely be nice to have support for Gamescope focusing correctly under upstream Wine as well. Fixes a bunch of games/launchers run with Wine under Gamescope. Signed-off-by: Joshua Ashton <joshua(a)froggi.es> --- dlls/winex11.drv/window.c | 17 +++++++++++++++++ dlls/winex11.drv/x11drv.h | 2 ++ dlls/winex11.drv/x11drv_main.c | 2 ++ 3 files changed, 21 insertions(+) diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c index 3b49b7e1d08..728f2417206 100644 --- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -1601,6 +1601,19 @@ Window create_client_window( HWND hwnd, const XVisualInfo *visual ) } +void set_hwnd_style_props( Display *display, Window window, HWND hwnd ) +{ + DWORD style = NtUserGetWindowLongW( hwnd, GWL_STYLE ), exstyle = NtUserGetWindowLongW( hwnd, GWL_EXSTYLE ); + + TRACE( "display %p, window %lx, hwnd %p\n", display, window, hwnd ); + + XChangeProperty( display, window, x11drv_atom(_WINE_HWND_STYLE), XA_CARDINAL, 32, + PropModeReplace, (unsigned char *)&style, sizeof(style) / 4 ); + XChangeProperty( display, window, x11drv_atom(_WINE_HWND_EXSTYLE), XA_CARDINAL, 32, + PropModeReplace, (unsigned char *)&exstyle, sizeof(exstyle) / 4 ); +} + + /********************************************************************** * create_whole_window * @@ -1653,6 +1666,8 @@ static void create_whole_window( struct x11drv_win_data *data ) XSaveContext( data->display, data->whole_window, winContext, (char *)data->hwnd ); NtUserSetProp( data->hwnd, whole_window_prop, (HANDLE)data->whole_window ); + set_hwnd_style_props( data->display, data->whole_window, data->hwnd ); + /* set the window text */ if (!NtUserInternalGetWindowText( data->hwnd, text, ARRAY_SIZE( text ))) text[0] = 0; sync_window_text( data->display, data->whole_window, text ); @@ -2647,6 +2662,8 @@ void X11DRV_WindowPosChanged( HWND hwnd, HWND insert_after, UINT swp_flags, return; } + set_hwnd_style_props( data->display, data->whole_window, data->hwnd ); + /* check if we are currently processing an event relevant to this window */ event_type = 0; if (thread_data && diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h index b8b134357d6..75763eb9a0c 100644 --- a/dlls/winex11.drv/x11drv.h +++ b/dlls/winex11.drv/x11drv.h @@ -517,6 +517,8 @@ enum x11drv_atoms XATOM__GTK_WORKAREAS_D0, XATOM__XEMBED, XATOM__XEMBED_INFO, + XATOM__WINE_HWND_STYLE, + XATOM__WINE_HWND_EXSTYLE, XATOM_XdndAware, XATOM_XdndEnter, XATOM_XdndPosition, diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c index 3fd6dcab254..4d764b2a47a 100644 --- a/dlls/winex11.drv/x11drv_main.c +++ b/dlls/winex11.drv/x11drv_main.c @@ -185,6 +185,8 @@ static const char * const atom_names[NB_XATOMS - FIRST_XATOM] = "_GTK_WORKAREAS_D0", "_XEMBED", "_XEMBED_INFO", + "_WINE_HWND_STYLE", + "_WINE_HWND_EXSTYLE", "XdndAware", "XdndEnter", "XdndPosition", -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/2902
I imagine there may be some concerns about exposing something that is specific to Gamescope, etc, but really this is an officially supported mechanism of Gamescope for it to make smarter windowing decisions that are simply not possible to express with X11 and the standard ICCCM properties. It would be really nice if certain games and launchers worked correctly under regular Wine as well as Proton. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_33850
On Thu May 25 18:06:17 2023 +0000, Joshua Ashton wrote:
I imagine there may be some concerns about exposing something that is specific to Gamescope, etc, but really this is an officially supported mechanism of Gamescope for it to make smarter windowing decisions that are simply not possible to express with X11 and the standard ICCCM properties. Gamescope is a very different type of compositor/WM compared to the others -- It is single window (+ dropdown) designed for a handheld/couch-type experience. We need more information than typical compositors/WMs to make informed decisions because of this. It would be really nice if certain games and launchers worked correctly under regular Wine as well as Proton. Thinking of `winewayland.drv` as well going forward: I think we would probably want some private Gamescope protocol to expose similar information. I would say xdg-shell stuff is even more limiting. :sweat_smile:
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_33853
If these are intended to be Gamescope properties, and at least in theory usable by non-Wine clients, I imagine we'd like them to use some prefix other than "\_WINE\_". -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_33919
On Fri May 26 18:20:22 2023 +0000, Henri Verbeet wrote:
If these are intended to be Gamescope properties, and at least in theory usable by non-Wine clients, I imagine we'd like them to use some prefix other than "\_WINE\_". I would prefer to keep the name, but I don't really have a strong opinion.
It is really Wine-specific, unless there's another Windows translation layer about. I certainly wouldn't encourage typical desktop clients/games to start using Win32 window styles at all... :frog: It just means more churn on the Gamescope side to support this under a new name. We'd have to support both of these names in perpetuity then to support older versions of Proton. If we were to give it a new name, do you have any suggestions? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_33967
Not a maintainer, so feel free to disregard: would it make sense to merge all Wine-specific window flags into a single property, so that we can extend it (due to e.g., Gamescope needs) in the future without occupying more atoms? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_34081
On Fri May 26 18:20:22 2023 +0000, Joshua Ashton wrote:
I would prefer to keep the name, but I don't really have a strong opinion. It is really Wine-specific, unless there's another Windows translation layer about. I certainly wouldn't encourage typical desktop clients/games to start using Win32 window styles at all... :frog: It just means more churn on the Gamescope side to support this under a new name. We'd have to support both of these names in perpetuity then to support older versions of Proton. If we were to give it a new name, do you have any suggestions? `_WINE_HWND_STYLE` and `_WINE_HWND_EXSTYLE` are fine.
I think `_WIN_HWND_(EX)STYLE` and `_WIN_HWND_(EX)STYLE` are valid alternatives too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_34556
On Sat Jun 3 12:19:56 2023 +0000, Jinoh Kang wrote:
Not a maintainer, so feel free to disregard: would it make sense to merge all Wine-specific window flags into a single property, so that we can extend it (due to e.g., Gamescope needs) in the future without occupying more atoms? Well, this has compatibility implication for long term.
If everything is put into one atom, window/display managers will have a hard time to adapt to the atom changes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_34558
I think exposing the two Win32 window attributes, as two pristine, and separate, X11 properties, is the straightforward thing to do. Trying to define something specific is only making things more complicated. Regarding the properties names, I think this is not some WM-specific behavior that Wine is implementing, but the opposite. We don't generally implement WM-specific behavior, and I believe we even try very hard not to, so if it were some Gamescope feature that Wine would have to implement I think it would not be acceptable. However, I think we can consider exposing more Wine internal information to the outside world, in case other tools want to adapt their behavior to Wine. This is not always desirable, and I understand that we may prefer not to, for instance as debugging Wine-aware applications can be more complicated when comparing with native behavior, but in this case I think it can be justified and should be considered. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_34564
I'm going to approve it to show some support, as this would make upstream Wine (not just Proton) work better with Gamescope, and as it could allow other WM interested to improve their behavior according to these flags. Then I'm probably not the only person you need to convince here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_46556
This merge request was approved by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902
To properly reflect style changes this should be done somewhere like `set_style_hints()`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2902#note_59913
participants (6)
-
Alexandre Julliard (＠julliard) -
Henri Verbeet (＠hverbeet)
-
Jinoh Kang (＠iamahuman)
-
Joshua Ashton (＠joshua)
-
Loïc Rebmeister
-
Rémi Bernon