June 2024 - wine-gitlab

[PATCH v5 0/4] MR5741: server: Implement key auto-repeat.
by Alexandros Frantzis (＠afrantzis) 06 Jun '24

06 Jun '24

This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions: 1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code). 2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves). Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all). -- v5: win32u: Implement keyboard auto-repeat using new server request. server: Implement key auto-repeat request. https://gitlab.winehq.org/wine/wine/-/merge_requests/5741

3 6

[PATCH v6 0/4] MR5741: server: Implement key auto-repeat.
by Alexandros Frantzis (＠afrantzis) 06 Jun '24

06 Jun '24

This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions: 1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code). 2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves). Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all). -- v6: win32u: Implement keyboard auto-repeat using new server request. server: Implement key auto-repeat request. https://gitlab.winehq.org/wine/wine/-/merge_requests/5741

2 5

[PATCH 0/5] MR5798: winemac: Push window surface updates to the main thread.
by Rémi Bernon (＠rbernon) 06 Jun '24

06 Jun '24

Instead of accessing the surface with macdrv_get_surface_display_image. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5798

2 6

[PATCH v3 0/5] MR5776: win32u: Parameterize DPI in some driver calls.
by Rémi Bernon (＠rbernon) 06 Jun '24

06 Jun '24

-- v3: win32u: Pass the rect DPI to NtUserIsWindowRectFullScreen. win32u: Introduce a new get_monitor_rect helper. win32u: Pass desired DPI to NtUserGet(Client|Window)Rect. win32u: Introduce NtUserAdjustWindowRect call for AdjustWindowRect*. win32u: Introduce new helpers to convert server rectangle_t. https://gitlab.winehq.org/wine/wine/-/merge_requests/5776

2 7

[PATCH v4 0/1] MR5333: vcruntime140_1: Pass original frame to catch block on stack.
by Daniel Lehman (＠dlehman25) 06 Jun '24

06 Jun '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56451 local variables with alignas(32) or higher may cause the unwinding code to fetch the original frame from a different spot on the stack from where the catch block code places it -- v4: vcruntime140_1: Pass original frame to catch block on stack. https://gitlab.winehq.org/wine/wine/-/merge_requests/5333

3 4

[PATCH 0/3] MR5797: wined3d: Miscellaneous.
by Elizabeth Figura (＠zfigura) 06 Jun '24

06 Jun '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5797

2 3

[PATCH 0/12] MR5796: kernelbase, ntdll: Implement DOS wildcards matching in NtQueryDirectoryFile and use that in FindFirstFile().
by Paul Gofman (＠gofman) 06 Jun '24

06 Jun '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5796

3 15

Re: [PATCH v4 0/1] MR3518: wininet: unify timeout values closer to hInternet
by Jacek Caban (＠jacek) 05 Jun '24

05 Jun '24

It looks better, thanks. In addition to minor comments, please split it. Additional `NETCON_set_timeout` fix is a separate fix from setting/getting options. Maybe also separate `NETCON_set_timeout` for send and receive. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3518#note_72542

1 0

Re: [PATCH v4 0/1] MR3518: wininet: unify timeout values closer to hInternet
by Jacek Caban (＠jacek) 05 Jun '24

05 Jun '24

Jacek Caban (@jacek) commented about dlls/wininet/http.c: > > if (maxlen == -1) maxlen = sizeof(req->read_buf); > > + NETCON_set_timeout(req->netconn, FALSE, req->hdr.receive_timeout); Setting the timeout on the socket is quite expensive (requires a wineserver call). Maybe we could store the last set timeout separate from configure timeout and update socket timeout only when they don't match? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3518#note_72541

1 0

Re: [PATCH v4 0/1] MR3518: wininet: unify timeout values closer to hInternet
by Jacek Caban (＠jacek) 05 Jun '24

05 Jun '24

Jacek Caban (@jacek) commented about dlls/wininet/internet.c: > + if (!lpwhh) > + { > + SetLastError(ERROR_INTERNET_INCORRECT_HANDLE_TYPE); > + return FALSE; > + } > + if (!lpBuffer || dwBufferLength != sizeof(ULONG)) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + ret = FALSE; > + } > + else > + { > + lpwhh->connect_timeout = *(ULONG *)lpBuffer; > + } > + break; > + } Do we still need it? I think that with implementation in both `set_global_option` and `INET_SetOption`, we could simply remove those cases from `InternetSetOptionW` fallback. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3518#note_72540

1 0

2025

2024

2023

2022

wine-gitlab June 2024