September 2024 - Wine-gitlab

[PATCH v5 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Ostap Brehin (＠osbre) 03 Sep '24

03 Sep '24

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) 03 Sep '24

03 Sep '24

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) 03 Sep '24

03 Sep '24

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) 03 Sep '24

03 Sep '24

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) 03 Sep '24

03 Sep '24

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 03 Sep '24

03 Sep '24

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

4 6

[PATCH 0/1] MR6438: winewayland: Delay setting user driver functions.
by Aida Jonikienė 03 Sep '24

03 Sep '24

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 03 Sep '24

03 Sep '24

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) 03 Sep '24

03 Sep '24

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

Re: [PATCH v5 0/2] MR6059: mf: Retry PROCESSINPUTNOTIFY if TRANSFORM_TYPE_NOT_SET is returned.
by Nikolay Sivov (＠nsivov) 03 Sep '24

03 Sep '24

On Tue Sep 3 13:56:42 2024 +0000, Brendan McGrath wrote: > @nsivov Are you happy with this MR as is? Or does it something else? I have a couple of comments, or maybe questions. Do you know how do we get in this state when it gets as far as ProcessSample(), but type is not set? SetCurrentMediaType() sets type both the mixer, and notifies the presenter. Do we need the same "loop" when other presenter methods fail similarly? Regarding MEError, is that only to unblock waits? What might be interesting to test is if all common error codes produce MEError and not MENonFatalError. Those are listed at IMFStreamSink::ProcessSample doc page. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6059#note_80861

1 0