September 2024 - Wine-GitLab

[PATCH v6 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Ostap Brehin (＠osbre) Sept. 3, 2024

Sept. 3, 2024

Source: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nc-winbase-lppr… -- v6: include: Name parameters in LPPROGRESS_ROUTINE typedef https://gitlab.winehq.org/wine/wine/-/merge_requests/6425

3 2

[PATCH v5 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Ostap Brehin (＠osbre) Sept. 3, 2024

Sept. 3, 2024

Source: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nc-winbase-lppr… -- v5: include: Name parameters in LPPROGRESS_ROUTINE typedef https://gitlab.winehq.org/wine/wine/-/merge_requests/6425

3 2

[PATCH v4 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Ostap Brehin (＠osbre) Sept. 3, 2024

Sept. 3, 2024

Source: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nc-winbase-lppr… -- v4: include: Name parameters in LPPROGRESS_ROUTINE typedef https://gitlab.winehq.org/wine/wine/-/merge_requests/6425

3 2

Re: [PATCH v3 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Alfred Agrell (＠Alcaro) Sept. 3, 2024

Sept. 3, 2024

On Tue Sep 3 17:43:38 2024 +0000, Ostap Brehin wrote: > Thank you! will update. > Regarding not devoting an entire line for each parameter - not sure if > that's possible due to enforced `max_line_length = 100` in > [.editorconfig](https://gitlab.winehq.org/wine/wine/-/blob/master/.editorconfig), > as then the new line size would be about 300 characters if that's the case. Or you can put 2-4 params per line. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6425#note_80919

1 0

Re: [PATCH v3 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Ostap Brehin (＠osbre) Sept. 3, 2024

Sept. 3, 2024

On Tue Sep 3 17:29:39 2024 +0000, Alex Henrie wrote: > If we're going to do this, can we please use `void *` instead of > `LPVOID`, name each parameter in snake_case, and not devote an entire > line to each parameter? Thank you! will update. Regarding not devoting an entire line for each parameter - not sure if that's possible due to enforced `max_line_length = 100` in [.editorconfig](https://gitlab.winehq.org/wine/wine/-/blob/master/.editorconfig), as then the new line size would be about 300 characters if that's the case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6425#note_80917

1 0

Re: [PATCH v3 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Alex Henrie (＠alexhenrie) Sept. 3, 2024

Sept. 3, 2024

Alex Henrie (@alexhenrie) commented about include/winbase.h: > * This one seems to be a Win32 only definition. It also is defined with > * WINAPI instead of CALLBACK in the windows headers. > */ > -typedef DWORD (CALLBACK *LPPROGRESS_ROUTINE)(LARGE_INTEGER, LARGE_INTEGER, LARGE_INTEGER, > - LARGE_INTEGER, DWORD, DWORD, HANDLE, > - HANDLE, LPVOID); > +typedef DWORD (CALLBACK *LPPROGRESS_ROUTINE)( > + LARGE_INTEGER TotalFileSize, > + LARGE_INTEGER TotalBytesTransferred, > + LARGE_INTEGER StreamSize, > + LARGE_INTEGER StreamBytesTransferred, > + DWORD dwStreamNumber, > + DWORD dwCallbackReason, > + HANDLE hSourceFile, > + HANDLE hDestinationFile, > + LPVOID lpData If we're going to do this, can we please use `void *` instead of `LPVOID`, name each parameter in snake_case, and not devote an entire line to each parameter? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6425#note_80916

1 0

[PATCH 0/1] MR6431: gitlab: Install FFmpeg development libraries.
by Rémi Bernon Sept. 3, 2024

Sept. 3, 2024

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

4 6

[PATCH 0/1] MR6438: winewayland: Delay setting user driver functions.
by Aida Jonikienė Sept. 3, 2024

Sept. 3, 2024

This fixes segfaults and explorer.exe being stuck when this driver fails to load. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6438

2 3

Re: [PATCH v2 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon Sept. 3, 2024

Sept. 3, 2024

On Tue Sep 3 14:53:44 2024 +0000, Jacek Caban wrote: > Could you please summarize what exactly we need to have access to from > win32u? The code looks correct. I can't say that the host handle union > is particularly pretty, but I think I could be fine with it. I'd still > like to understand why something lighter is not enough. > For modifying handle mapping, I guess that the reasoning is that > surfaces/swapchains may change the underlying actual host handle during > their lifetime and we want that reflected in debug callbacks. One > alternative approach for that would be to report an opaque win32u handle > to winevulkan (so that it's constant from winevulkan's point of view) > and have a separate host->win32u opaque unwrapping in win32u. > I also recall a problem accessing object's parents outside winevulkan. > For that, sharing just specific bits of structs implementing handles > could be enough. * winevulkan needs to access any wrapper host handle (through the vulkan_object->host union), so that it can unwrap in the generated code. * win32u needs to access the wrapper host handle to unwrap them when it calls into the host functions. * win32u needs to access the parent object chain, and the device/instance functions, in order to call the right host functions from its parent device/instance. [^1] * win32u needs to access the instance object tree and lock, to register newly created wrappers as instance objects. To register the mappings it also needs to access the client handle of a wrapper, although for swapchain and surface that's the wrapper itself. [^2] [^1]: We could selectively expose them in a separate table, but it seems simpler to just expose the full table. It also makes it possible to query more host functions in advance for unix side only extensions, and use the function tables for everything. [^2]: I don't think the handles would ever change, but being able to register wrappers from win32u makes things simpler because we then don't need a manual function in winevulkan to register the objects, and the winevulkan thunks can call directly into win32u functions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_80867

1 0

Re: [PATCH v2 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Jacek Caban (＠jacek) Sept. 3, 2024

Sept. 3, 2024

Could you please summarize what exactly we need to have access to from win32u? The code looks correct. I can't say that the host handle union is particularly pretty, but I think I could be fine with it. I'd still like to understand why something lighter is not enough. For modifying handle mapping, I guess that the reasoning is that surfaces/swapchains may change the underlying actual host handle during their lifetime and we want that reflected in debug callbacks. One alternative approach for that would be to report an opaque win32u handle to winevulkan (so that it's constant from winevulkan's point of view) and have a separate host->win32u opaque unwrapping in win32u. I also recall a problem accessing object's parents outside winevulkan. For that, sharing just specific bits of structs implementing handles could be enough. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_80863

1 0