August 2024 - Wine-gitlab - list.winehq.org

Re: [PATCH v5 0/5] MR6386: winewayland: Reduce window surface buffer queue recreations. - approved
by Alexandros Frantzis (＠afrantzis) 30 Aug '24

30 Aug '24

This merge request was approved by Alexandros Frantzis. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6386

1 0

Re: [PATCH v5 0/5] MR6386: winewayland: Reduce window surface buffer queue recreations.
by Alexandros Frantzis (＠afrantzis) 30 Aug '24

30 Aug '24

Thanks, LGTM! Note that with this MR we can sometimes get artifacts in GL applications such as: ![artifact](/uploads/1bb34fa9cefc1187e4edaebe65242497/artifact.png) However this is not a problem with the change itself, but rather this change is interacting with two existing deficiencies in the driver: 1. `wayland_window_surface_set_clip()` is not implemented, hence we get such artifacts in our committed window surface buffers. 2. OpenGL surfaces not presented opaquely hence we can actually see the artifacts in the window surface behind the GL subsurface. We might want to revisit using EGL_EXT_present_opaque now that https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153 has been merged, although this would require a Mesa version check in the Wayland driver to use the feature safely. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6386#note_80510

1 0

[PATCH 0/3] MR6407: include: Updated a few gdiplus types.
by Alistair Leslie-Hughes (＠alesliehughes) 30 Aug '24

30 Aug '24

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

3 4

[PATCH 0/1] MR6406: include: Add input assembler related constants in d3d11.idl
by Biswapriyo Nath (＠Biswa96) 30 Aug '24

30 Aug '24

Required for https://github.com/microsoft/DirectXTK/blob/jun2024/Src/ModelLoadSDKMESH.cp… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6406

3 2

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Rémi Bernon 30 Aug '24

30 Aug '24

> @rbernon I'm okay with using reserved as an offset to pass the device path, but we'd still have to pass it for every message for filtering. I didn't want to utilize `reserved` mostly out of caution, if it ever turned out to be that the field did have some undocumented semantics after all. Maybe we can avoid sending the paths every time by moving the filtering to plugplay, adapting the interface a bit for this. There could be additional methods to register paths / get plugplay handles in return, and later use these handle as device handles. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80507

1 0

[PATCH 0/1] MR6404: packager: Prefer native version.
by Elizabeth Figura (＠zfigura) 30 Aug '24

30 Aug '24

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

2 2

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 30 Aug '24

30 Aug '24

On Thu Aug 29 23:38:23 2024 +0000, Vibhav Pant wrote: > @zfigura Testing it is tricky. My plan was to utilize it in the > bluetooth driver by directly calling `plugplay_send_event` from the > driver code itself, and I'm not sure what the equivalent of that would > be in Windows. > @rbernon I'm okay with using reserved as an offset to pass the device > path, but we'd still have to pass it for every message for filtering. I > didn't want to utilize `reserved` mostly out of caution, if it ever > turned out to be that the field did have some undocumented semantics > after all. After doing a bit of research, I believe the Windows interface is IoReportTargetDeviceChange(). See [1], which mentions using that function to report the device notification, and that user mode should register for it with RegisterDeviceNotification(). That function is probably only used for DBT_DEVTYP_HANDLE. I suspect there is no public interface for DBT_DEVTYP_DEVICEINTERFACE. The corresponding kernel-mode identifier for that one is EventCategoryDeviceInterfaceChange, but I suspect that IoReportTargetDeviceChange() only deals with EventCategoryTargetDeviceChange. This would make sense since device interface notifications should only be generated by the kernel anyway. [I have no idea about the other DBT_DEVTYPE_* values. Are they even ever sent in NT?] [1] https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-pnp… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80501

1 0

Re: [PATCH v7 0/1] MR6299: ntdll: Determine the available address space dynamically for 64bit architectures.
by Garrett Mesmer (＠gmesmer) 30 Aug '24

30 Aug '24

On Fri Aug 30 02:21:05 2024 +0000, Alexandre Julliard wrote: > Much better, thanks. Could you please fix the authorship information in > the commit to use your full name? My apologies. I thought the authorship name was supposed to match the gitlab username instead of full name. It is corrected now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6299#note_80500

1 0

Re: [PATCH v5 0/1] MR5509: Add tests to MF Media Engine
by Brendan McGrath (＠redmcg) 30 Aug '24

30 Aug '24

@nsivov Should I close this one? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5509#note_80498

1 0

[PATCH v2 0/1] MR5978: winegstreamer: Optimise copy to DXGI buffer.
by Brendan McGrath (＠redmcg) 30 Aug '24

30 Aug '24

Using IMF2DBuffer2_Lock2DSize with LockFlags_Write dramatically improves performance over IMFMediaBuffer_Lock when using a DXGI buffer. IMFMediaBuffer_Lock does not know that this buffer will not be read and therefore performs an unnecessary transfer of the texture from GPU to CPU before it is overwritten. -- v2: winegstreamer: Optimise copy to DXGI buffer. https://gitlab.winehq.org/wine/wine/-/merge_requests/5978

3 7