Test that DragDetect() uses client coordinates instead of screen coordinates even though MSDN says that DragDetect()
should use screen coordinates. This also means that Wine's current implementation is correct.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6586
wintab32 is currently broken in the new wow64 mode because the `tablet_get_packet` thunk in winex11.drv is not implemented. Since the structure it is copying is entirely internal to Wine, and the HCTX handle value is not actually read or written by the driver side, I found that simply padding the structure to keep the rest of it aligned was enough to make wow64 happy and allow wintab32 to function.
This is somewhat a stopgap. What would be much better is to refactor the wintab code such that more of the logic is in the wintab32 implementation and not the driver. My goal is to accomplish this as part of trying to get my winewayland graphics tablet patch into an acceptable state for upstreaming. However, I think this is still a worthwhile improvement to have in the interim, if it is acceptable.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6584
Fix the wayland side of https://bugs.winehq.org/show_bug.cgi?id=55336
### Exit menu key by default:
That's the actual behavior, any non-special key will exit the menu key, and be sent to the client.
I was also wondering if we should add `menu_sys_key = f10_key = 0;` when receiving a `WM_ACTIVATE` in `win32u/defwnd.c`'s `default_window_proc` but I guess not ?
### Fix repeated key for no reason:
For some reason when ALT is pressed, it is spammed and thus spams SYS_COMMAND. This fix that, but I don't know what I am doing here. I don't see any repeating key spamming with winex11 but I could be wrong. However alt/SYS_COMMAND should not be repeated.
That wasn't happening with winex11.drv.
### Fix release_all_keys modifier filtering:
That was the main reason why alt-tab leads to the menu key, NtUserGetAsyncKeyboardState also uses left and right system keys.
### Fix release_all_keys scan value:
This one is wrong, a failed attempt. The actual problem is that NtUserGetAsyncKeyboardState limits itself to 256 virtual keys, discarding the extended scan code info. So it results on my down arrow being kept repeated while being focused out, and when focused in, pressing the arrow again is needed to stop the repeat.
Also using the KEYEVENTF_SCANCODE flag results in win32u/message.c's send_hardware_message calling NtUserGetKeyboardLayout which get a incorect hkl value but it doesn't seems to have an impact.
--
v3: winewayland.drv: Fix release_all_keys modifier filtering
server: Fix repeated key for no reason
win32u: Exit menu key by default
https://gitlab.winehq.org/wine/wine/-/merge_requests/6199
--
v2: dplayx: Set player data in DP_CreatePlayer().
dplayx: Add player to the system group in DP_CreatePlayer().
dplayx: Don't enumerate system players.
dplayx/tests: Test that players from SUPERENUMPLAYERSREPLY are added to the session.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6575
--
v5: winewayland: Use subsurfaces for unmanaged windows.
winewayland: Introduce a new update_wayland_surface_state_toplevel helper.
winewayland: Introduce a new wayland_surface_reconfigure_xdg helper.
winewayland: Introduce a new wayland_surface role enumeration.
winewayland: Call wayland_surface_clear_role in wayland_surface_destroy.
winewayland: Move surface title change to wayland_surface_make_toplevel.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560
On Sat Sep 21 20:51:46 2024 +0000, Philipp Knechtges wrote:
> TBH, I do not really know what to make of this assessment. Looking at
> the d2d1 tests it feels like, correctness is at best achieved
> approximately, and then the question arises what is the metric in which
> "correctness" is assessed? Unarguably, the tests as a metric are a
> moving target, depending on when which tests are added, thus making it a
> subjective choice at times.
> In my book, the patch at hand makes the rendering more correct in many
> cases. To be precise in all cases in which the individual geometries in
> the geometry group do not intersect, and thus the fill mode does not
> matter. Would you consider the patch sufficient, if it would
> (approximately) check for intersections and only copy if there are none,
> and falling back to old behavior (rendering just nothing) in case there
> are any (potentially false-positive) intersections?
It wouldn't consider it sufficient, it's clear that there is more to it than copying data from individual geometries. So the question is the same - what needs to be done to make it work properly, once it's understood, we could implement it partially if it's too hard to do properly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_83622
--
v3: propsys: Initially implement PropVariantToVariant.
propsys: Support converting clsid to string for PropVariant.
propsys/tests: Test converting clsid to string.
propsys/tests: Add tests for PropVariantToVariant.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6526
This MR adds a unixlib component to wlanapi containing DBus + NetworkManager implementations for
* WlanEnumInterfaces
* WlanGetAvailableNetworkList
* WlanGetAvailableNetworkList
* WlanGetNetworkBssList
* WlanScan
--
v11: wlanapi: Add NetworkManager backed implementation for WlanGetProfileList.
wlanapi/tests: Add unit tests for WlanGetProfileList.
wlanapi: Add stub for WlanGetProfileList.
wlanapi: Add NetworkManager backed implementation for WlanScan.
wlanapi/tests: Add unit tests for WlanScan.
wlanapi: Add NetworkManager backed implementation for WlanGetNetworkBssList.
wlanapi/tests: Add unit test for test_WlanGetNetworkBssList.
wlanapi: Add stub for WlanGetNetworkBssList.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6505
--
v4: server: Eliminate async_alerted() helper function.
server: Eliminate async_unknown_status() helper function.
server: Remove "unknown_status" field from struct async.
server: Remove "alerted" field from struct async.
server: Remove "terminated" field from struct async.
server: Remove "signaled" field from struct async.
server: Remove "direct_result" field from struct async.
server: Signal async unconditionally in async_set_result().
server: Introduce a new async state enum.
server: Introduce async_unknown_status() helper to compute the 'unknown_status' flag.
server: Introduce async_alerted() helper to compute the 'alerted' flag.
server: Introduce async_terminated() helper to compute the 'terminated' flag.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6369
This is part XXVI of cmd engine rewrite.
It mainly tackles which variable name (single letter) are supported as FOR
loop variables.
We recently extended the scope of letters (a-z, A-Z) with digits (0-9).
A couple of bug reports show that more are supported.
More manual testing show that all 7bit ASCII characters are supported
(except the ones handled by lexer like CR, LR, \0, <SPACE>, <TAB>,
ctrl-Z...).
This serie:
- add a couple of new tests for FOR loop variables (also testing limits
on tokens= options for setting at once several contiguous variables)
- fix all exhibited bugs
- rewrite parsing and handling of tokens= option (simplicity, correctness).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6577
On Fri Sep 27 19:01:11 2024 +0000, Bernhard Kölbl wrote:
> changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/6572/diffs?diff_id=134822&start_sha=a9da1eec6e4aa3e8bdb288a7ca0a55b77ecc20f4#c77952b7e5c5034e6cd70f9f831c65dd50823d78_267_267)
Yeah, I messed that up, hope it's better now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6572#note_83570
--
v2: win32u: Use the current display mode as monitor rect.
win32u: Keep track of the display source physical display mode.
win32u: Add virtual modes when drivers report a single display mode.
win32u: Remove unnecessary GetCurrentDisplaySettings call.
win32u: Cache display source current display settings.
win32u: Remove now unnecessary GetDisplayDepth driver entry.
win32u: Keep the source depth separately from the current mode.
win32u: Always write the source current mode to the registry.
win32u: Make sure to load drivers when updating the display cache.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6573
--
v4: winewayland: Use subsurfaces for unmanaged windows.
winewayland: Introduce a new update_wayland_surface_state_toplevel helper.
winewayland: Introduce a new wayland_surface_reconfigure_xdg helper.
winewayland: Introduce a new wayland_surface role enumeration.
winewayland: Call wayland_surface_clear_role in wayland_surface_destroy.
winewayland: Move surface title change to wayland_surface_make_toplevel.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560
Instead of a single configure serial, which is simply not enough to
mitigate event feedback loops.
This should (hopefully) address the recent d3d8:device / d3d9:device
test failures on the Gitlab CI, without having to add more `flush_events`
calls to the tests.
I believe it should also provide a more general fix to this race condition
than the configure_serial mechanism.
--
v4: winex11: Also discard near-matching configs with similar sizes.
winex11: Keep a list of pending window config requests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569
Instead of a single configure serial, which is simply not enough to
mitigate event feedback loops.
This should (hopefully) address the recent d3d8:device / d3d9:device
test failures on the Gitlab CI, without having to add more `flush_events`
calls to the tests.
I believe it should also provide a more general fix to this race condition
than the configure_serial mechanism.
--
v3: winex11: Also discard near-matching configs with similar sizes.
winex11: Keep a list of pending window config requests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569
Instead of a single configure serial, which is simply not enough to
mitigate event feedback loops.
This should (hopefully) address the recent d3d8:device / d3d9:device
test failures on the Gitlab CI, without having to add more `flush_events`
calls to the tests.
I believe it should also provide a more general fix to this race condition
than the configure_serial mechanism.
--
v2: winex11: Also discard near-matching configs with similar sizes.
winex11: Keep a list of pending window config requests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569
Instead of a single configure serial, which is simply not enough to
mitigate event feedback loops.
This should (hopefully) address the recent d3d8:device / d3d9:device
test failures on the Gitlab CI, without having to add more `flush_events`
calls to the tests.
I believe it should also provide a more general fix to this race condition
than the configure_serial mechanism.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569
--
v3: winewayland: Use subsurfaces for unmanaged windows.
winewayland: Introduce a new update_wayland_surface_state_toplevel helper.
winewayland: Introduce a new wayland_surface_reconfigure_xdg helper.
winewayland: Introduce a new wayland_surface role enumeration.
winewayland: Call wayland_surface_clear_role in wayland_surface_destroy.
winewayland: Move surface title change to wayland_surface_make_toplevel.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560
The tests show how recent Windows use per-monitor DPI to implement virtual display settings. This is only the case on the w11pro64_nv and w11pro64_amd virtual machines, and the other VMs only support per-monitor DPI scaling. Both these two scaling add up, and their effect is exposed by the GetDpiForMonitorInternal call, with the ANGULAR and RAW dpi flavors.
--
v2: user32/tests: Add tests with windows and monitor DPI scaling.
user32/tests: Add more tests with display source DPI scaling.
user32/tests: Add more tests for GetDpiForMonitorInternal.
user32: Stub DisplayConfigSetDeviceInfo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6566
The tests show how recent Windows use per-monitor DPI to implement virtual display settings. This is only the case on the w11pro64_nv and w11pro64_amd virtual machines, and the other VMs only support per-monitor DPI scaling. Both these two scaling add up, and their effect is exposed by the GetDpiForMonitorInternal call, with the ANGULAR and RAW dpi flavors.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6566
Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/window.c:
> /* Get the managed state with win_data unlocked, as is_window_managed
> * may need to query win_data information about other HWNDs and thus
> * acquire the lock itself internally. */
> - managed = is_window_managed(hwnd, swp_flags, &new_rects->window);
> + if (!(managed = is_window_managed(hwnd, swp_flags, &new_rects->window)) && surface)
> + {
> + toplevel = NtUserGetWindowRelative(hwnd, GW_OWNER);
> + if (toplevel) toplevel = NtUserGetAncestor(toplevel, GA_ROOT);
> + /* fallback to any window that is right below our top left corner */
> + if (!toplevel) toplevel = NtUserWindowFromPoint(new_rects->window.left - 1, new_rects->window.top - 1);
If I am reading the docs correctly `NtUserWindowFromPoint()` can return child windows in which case anchoring won't work. If we move this above the `NtUserGetAncestor(toplevel, GA_ROOT)` a couple of lines above we will we get a proper toplevel in all cases. Are there any downsides to this?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83412
On Thu Sep 26 07:05:10 2024 +0000, Alexandros Frantzis wrote:
> The core problem seems to be that in
> `wayland_win_data_update_wayland_state` `surface->role` is used to
> determine what's the *current* role for the surface. However
> `surface->role` is really tracking what role was given in the past to
> this surface and thus can be given again in the future (because surfaces
> cannot change roles).
> In this particular osu! case, we have a previously toplevel surface (so
> surface->role = toplevel) that is now role-less, but
> `wayland_surface_update_state_toplevel` is called on it, which then
> unconditionally tries to access the NULL xdg_toplevel and crashes the
> thread while holding the 'win_data_mutex` lock.
One fix is to add `if (!surface->xdg_toplevel) return;` at the beginning of `wayland_surface_update_state_toplevel()`. It depends on what we want `surface->role` to mean. If it is "possible role" (which seems to match how other parts of the code are implemented) then this should be OK.
Alternatively, perhaps a more explicit arrangement `surface->role` vs `surface->possible_role` would make things clearer?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83411
On Thu Sep 26 06:38:50 2024 +0000, William Horvath wrote:
> It starts occurring after commit 5/6 (af65d37c Introduce
> update_wayland_surface_state_toplevel). Reverting to the previous commit
> 4/6, 35c90946 Introduce wayland_surface_reconfigure_xdg, it behaves normally.
The core problem seems to be that in `wayland_win_data_update_wayland_state` `surface->role` is used to determine what's the *current* role for the surface. However `surface->role` is really tracking what role was given in the past to this surface and thus can be given again in the future (because surfaces cannot change roles).
In this particular osu! case, we have a previously toplevel surface (so surface->role = toplevel) that is now role-less, but `wayland_surface_update_state_toplevel` is called on it, which then unconditionally tries to access the NULL xdg_toplevel and crashes the thread while holding the 'win_data_mutex` lock.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83410
On Thu Sep 26 06:15:21 2024 +0000, Aida Jonikienė wrote:
> Can you try bisecting the individual MR commits? :frog:
It starts occurring after commit 5/6 (af65d37c Introduce update_wayland_surface_state_toplevel). Reverting to the previous commit 4/6, 35c90946 Introduce wayland_surface_reconfigure_xdg, it behaves normally.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83409
On Thu Sep 26 06:15:21 2024 +0000, William Horvath wrote:
> Applying this MR on top of `2b32c285` (master) prevents
> [osu!](https://osu.ppy.sh/)
> ([download](https://m1.ppy.sh/r/osu!install.exe)) from closing when the
> either the ingame "Fullscreen" or "Render at native resolution" options
> are enabled (i.e. no window frame). I don't want to speculate too much,
> but it seems that an invisible window just never closes, preventing
> Wine/the game from closing until a `wineserver -k` is sent. Only native
> dotnet48 is installed in the prefix.
> [fullscreen.log (hangs)](/uploads/8f2dc854833b96f4c84796b04edcbf57/fullscreen.log)
> [nofullscreen.log (closes properly)](/uploads/7ce90e3ad7adddb4f6fc7e2efbb05543/nofullscreen.log)
> Here are logs of
> `WINEDEBUG=+pid,+tid,+timestamp,+loaddll,+win,+waylanddrv` with both
> fullscreen enabled and disabled. There may be more useful debug channels
> that I'm missing.
>
> Also, irrelevant to this regression, but I believe that the
> `GetRawInputDeviceInfoA` spam is due to a different bug somewhere in wine(bus|hid|usb).
Can you try bisecting the individual MR commits? :frog:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83408
Applying this MR on top of `2b32c285` (master) prevents [osu!](https://osu.ppy.sh/) ([download](https://m1.ppy.sh/r/osu!install.exe)) from closing when the either the ingame "Fullscreen" or "Render at native resolution" options are enabled (i.e. no window frame). It just hangs indefinitely, due to a deadlock I presume. Only native dotnet48 is installed in the prefix.
[fullscreen.log (hangs)](/uploads/8f2dc854833b96f4c84796b04edcbf57/fullscreen.log)
[nofullscreen.log (closes properly)](/uploads/7ce90e3ad7adddb4f6fc7e2efbb05543/nofullscreen.log)
Here are logs of `WINEDEBUG=+pid,+tid,+timestamp,+loaddll,+win,+waylanddrv` with both fullscreen enabled and disabled, but I don't know if there's a more useful channel that I'm missing.
Also, irrelevant to this regression, but the `GetRawInputDeviceInfoA` spam on the `win` channel is due to a different bug somewhere in wine(bus|hid|usb).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83395
On Wed Sep 25 10:48:29 2024 +0000, Aida Jonikienė wrote:
> Clipboard support is completely missing which was present on the
> downstream driver (and exposing multiple display modes too but that may
> be related to virtual display stuff)
Does resolution scaling still ignore aspect ratio for fullscreen games? That's one small bit that I noticed while testing the Wayland driver.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6560#note_83343
create_offscreen_window_surface() expects to borrow a reference from
*window_surface argument if it is not NULL.
Fixes: 8dd4b62e4c7 (win32u: Move offscreen window surface creation fallback., 2024-06-27)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6561
This will allow parsing and compiling shaders a bit later, which is useful for FFP. It will also help if we want to collect together shader initialization to go through a single entry point instead of six individual ones.
--
v2: wined3d: Merge the rest of pixel_shader_init() into shader_set_function().
wined3d: Merge the rest of vertex_shader_init() into shader_set_function().
https://gitlab.winehq.org/wine/wine/-/merge_requests/6556
This will allow parsing and compiling shaders a bit later, which is useful for FFP. It will also help if we want to collect together shader initialization to go through a single entry point instead of six individual ones.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6556
At the moment GL/VK content can only be presented in top-level windows, since child windows are not backed by Wayland surfaces. This MR adds support for such scenarios, in a few gradual steps:
1. Create Wayland (sub)surfaces for all child windows, anchoring them to their parent surface, which may also be a child window surface (i.e., we support GL/VK in nested child windows). This approach works, but it pollutes the compositor with mostly unused, and possibly nested (sub)surfaces. We will deal with this later in the MR.
2. Ensure that the child window (sub)surfaces are properly updated and reconfigured, and support WS_POPUP <-> WS_CHILD style changes (reparenting etc).
3. In the second to last commit, improve efficiency by creating (sub)surfaces only for the child windows needed by GL/VK, and anchor them directly to the parent toplevel. This removes (sub)surface bloat and unnecessary nesting, the trade-off being some extra complexity when dealing with updates.
4. Finally improve the display of GDI content along with accelerated content.
Note that this MR doesn't clip GL/VK child window contents at the moment.
The subsurface mechanism introduced in this MR could also handle other kinds of windows in the future, for example display and properly position transient windows, menus etc.
--
v4: winewayland: Create Wayland surfaces for child windows on demand.
winewayland: Ensure parent surface contents for accelerated windows.
winewayland: Support Wayland surface role changes.
win32u: Update children window state when the parent state changes.
winewayland: Post WM_WAYLAND_CONFIGURE outside of the surface lock.
winewayland: Use weak references for parent wayland_surfaces.
winewayland: Handle subsurface reconfiguration.
winewayland: Create subsurfaces for child windows.
winewayland: Store all window rects in wayland_win_data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6107
Test Driver Unlimited Solar Crown depends on that (both calling ProcessTlsInformation and hotpatches the same to fixup the thread local storage allocation from ntdll).
--
v2: ntdll: Match memory allocation layout for ThreadLocalStoragePointer.
ntdll: Use NtSetInformationProcess( ProcessTlsInformation ) in alloc_tls_slot().
ntdll: Implement NtSetInformationProcess( ProcessTlsInformation ).
ntdll/tests: Add tests for NtSetInformationProcess( ProcessTlsInformation ).
https://gitlab.winehq.org/wine/wine/-/merge_requests/6549