September 2024 - Wine-gitlab

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

[PATCH 0/4] MR6437: ntoskrnl: Implement IoReportTargetDeviceChange
by Vibhav Pant (＠vibhavp) 03 Sep '24

03 Sep '24

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

3 5

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events. - closed
by Vibhav Pant (＠vibhavp) 03 Sep '24

03 Sep '24

This merge request was closed by Vibhav Pant. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

1 0

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 03 Sep '24

03 Sep '24

On Sat Aug 31 17:49:29 2024 +0000, Rémi Bernon wrote: > > If you're referring to the new RPC structs, I understand. That being > said, my one concern is whether stuffing the file path into `dbch_data` > could potentially break some code out there that uses `dbch_size` to > guess which event is being sent (something like `if (n->dbch_size == > (sizeof(DEV_BROADCAST_HANDLE) + sizeof(BTH_RADIO_IN_RANGE)`). It is an > extremely stupid way to check for the event, but I'm not sure whether > someone doing this can be safely discounted. I'll write some test code > to see if this can be done on Windows to begin with. > But as far as I understand, as `plugplay_send_event` is completely > non-standard, these structs are only ever sent internally? So you don't > really need to bother about abusing some fields or size for the internal > notification, you even considered using custom structs which you would > convert back and forth on both sides. > Simply put whatever you need in the DEV_BROADCAST_HANDLE struct you > send, using any unused field, or some other way, to put the device path > in it if you need that, and just make sure you fix it up to a correct > DEV_BROADCAST_HANDLE struct before calling the notification callback? > Although I don't feel like it's even worth it you could even use a > custom DEV_BROADCAST_HDR based struct, or extend DEV_BROADCAST_HANDLE > with a custom derived struct which has an explicit device path, for the > internal messages. I just don't think you need to change the > DEV_BROADCAST_HDR base, or change the DEV_BROADCAST_DEVICEINTERFACE code > in any significant way for this. I have re-written this series to use `dbch_reserved` and implement `IoReportTargetDeviceChange` here, so I'll close this MR: https://gitlab.winehq.org/wine/wine/-/merge_requests/6437 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80855

1 0

[PATCH v2 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… -- v2: include: Name parameters in LPPROGRESS_ROUTINE typedef https://gitlab.winehq.org/wine/wine/-/merge_requests/6425

3 3

Re: [PATCH v3 0/1] MR6425: include: Name parameters in LPPROGRESS_ROUTINE typedef
by Nikolay Sivov (＠nsivov) 03 Sep '24

03 Sep '24

On Tue Sep 3 11:03:31 2024 +0000, Ostap Brehin wrote: > @Alcaro Thanks! I changed it back to `CALLBACK` now, it was a typo on my side. Current SDK has is with WINAPI, and so do mingw-w64 headers. Which again, won't make any difference in practice. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6425#note_80851

1 0

[PATCH 0/2] MR6401: uxtheme: Optimize drawing by avoiding unneeded TransparentBlt().
by Paul Gofman (＠gofman) 03 Sep '24

03 Sep '24

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

4 13

[PATCH 0/2] MR6433: dssenh: Add support for enumerating algorithms.
by Dmitry Timoshkov (＠dmitry) 03 Sep '24

03 Sep '24

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

4 4