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

[PATCH 0/4] MR5517: Draft: RFC: Move wglDescribePixelFormat implementation to opengl32
by Alexandros Frantzis (＠afrantzis) 28 May '24

28 May '24

As an intermediate step on the way to !5388, I wanted to focus on the infrastructure that will allow us to pass pixel format information from the driver to the PE side. This MR introduces the mechanism to perform this information exchange and uses it to implement `wglDescribePixelFormat` on the PE side. In the current RFC state this MR: 1. Introduces `p_get_pixel_format` driver API to allow drivers to provide pixel format information. 2. Implements `wglDescribePixelFormat` on the PE side using the pixel format information. If the driver doesn't implement `p_get_pixel_format` we fall back to the `wglDescribePixelFormat` driver implementation (temporary measure until all drivers are updated). 3. Caches pixel format information in `NtCurrentTeb()->glReserved1[]`. 4. Implements `p_get_pixel_format` API and removes the custom `wglDescribePixelFormat` for winewayland. At this point would like to get some more feedback about this approach and the technical details. If the direction seems promising, here are the next steps to get to a final MR: 1. Implement `p_get_pixel_format` for winex11, winemac and dibdrv and remove their custom `wglDescribePixelFormat` implementations. 2. Remove the `wglDescribePixelFormat` driver API. Thanks! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5517

3 7

[PATCH v5 0/3] MR5400: shell32: Tying up some loose ends
by Yuxuan Shui (＠yshui) 28 May '24

28 May '24

Follow up to !5342. This adds the last missing piece for fixing how `ShellExecute` finds files, and restore the ability of running native unix programs with `ShellExecute` -- v5: shell32: Restore the ability of running native unix programs with ShellExecute https://gitlab.winehq.org/wine/wine/-/merge_requests/5400

5 11

[PATCH 0/10] MR5508: Draft: winestreamer/video_decoder: Use video_decoder to implement wmv decoder.
by Ziqing Hui (＠zhui) 28 May '24

28 May '24

based on !5504 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5508

3 13

Re: [PATCH v8 0/2] MR5178: winewayland.drv: set wayland app-id from the process name
by Alexandros Frantzis (＠afrantzis) 28 May '24

28 May '24

On Mon Apr 22 09:02:12 2024 +0000, Shmerl wrote: > @afrantzis: A gentle ping. Can you please review and merge this? Hi @shmerl, I have already reviewed and approved this MR (and cannot merge myself). I guess it has fallen through the cracks, or perhaps @julliard and/or @rbernon would like to review themselves? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5178#note_68401

1 0

[PATCH v2 0/1] MR5518: windowscodecs: Support 32-bit ABGR bitfields bitmaps.
by Piotr Caban (＠piotr) 28 May '24

28 May '24

-- v2: windowscodecs: Support 32-bit ABGR bitfields bitmaps. https://gitlab.winehq.org/wine/wine/-/merge_requests/5518

3 3

Re: [PATCH v8 0/2] MR5178: winewayland.drv: set wayland app-id from the process name
by Shmerl (＠shmerl) 28 May '24

28 May '24

@afrantzis: A gentle ping. Can you please review and merge this? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5178#note_68246

1 0

[PATCH 0/1] MR5518: windowscodecs: Support 32-bit ABGR bitfields bitmaps.
by Piotr Caban (＠piotr) 28 May '24

28 May '24

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

3 2

Re: [PATCH v2 0/3] MR2404: ddraw: Two improvements for Prince of Persia 3D.
by Matteo Bruni (＠Mystral) 28 May '24

28 May '24

> > > I guess it should perform better with a vidmem buffer if the buffer is holding static data and not locked after the initial upload. > > Maybe, yeah. Though I'd be surprised if a ddraw application did that... That was basically the original idea behind vertex buffers: to hold static data in video memory so that's faster to access by the GPU (mostly in the sense of avoiding data transfers from SYSMEM). Similar idea behind ProcessVertices(). If you wanted to draw with dynamic data, you'd use the non-VB Draw[Indexed]Primitive variant. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2404#note_68209

1 0

[PATCH 0/1] MR5519: setupapi: use INF parser to read class GUID and class name
by Tuomas Räsänen 28 May '24

28 May '24

Previously, `SetupDiGetINFClassW()` read INF files with `GetPrivateProfileString()`, which does not substitute %strkey% tokens. This caused device installation to fail for devices which had driver INF files using %strkey% tokens in Version section. An example of such device is Vernier LabQuest Mini (08f7:0008) for which Vernier's LoggerPro application includes a driver. The INF file in question adds a new device setup class and has following entries in Version section: ``` Class = %ClassName% ClassGuid = %DeviceClassGUID% ``` Strings section includes following entries: ``` DeviceClassGUID = "{6B8429BF-10AD-4b66-9FBA-2FE72B891721}" ClassName = "VST_WinUSB" ``` Previously, when LoggerPro was installed and LabQuest Mini was hotplugged, device installation failed with the following error: ``` fixme:setupapi:SetupDiGetINFClassW failed to convert "L"%DeviceClassGUID"" into a guid ``` This caused GUID_NULL to be used and Class was not set to the registry for the device. With this commit, correct class GUID and names are set to the device registry entry. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56579 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5519

2 2

Re: [PATCH v2 0/3] MR2404: ddraw: Two improvements for Prince of Persia 3D.
by Elizabeth Figura (＠zfigura) 28 May '24

28 May '24

> It may be worth including a call to GetVertexBufferDesc() in the tests. As Matteo mentioned in an earlier comment, the docs seem to suggest that omitting D3DVBCAPS_SYSTEMMEMORY allows the driver/runtime to place the buffer as it sees fit. I mentioned earlier that GetVertexBufferDesc() never returns anything other than the flags used to create the buffer. That holds for both cards. I'll add a test the the suite. > I guess it should perform better with a vidmem buffer if the buffer is holding static data and not locked after the initial upload. Maybe, yeah. Though I'd be surprised if a ddraw application did that... > Can you check D3DDEVICEDESC.dwMaxVertexCount on these cards? Regardless of what we do with these two patches I think we should reduce it to whatever Windows reports. (1024 in my case on Windows 11) For both cards, the RGB device has 0 in the HAL caps, and 2021 in the HEL caps. The NVidia card has 32768 (both HAL and HEL), and the ATI card has 2048 (both HAL and HEL). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2404#note_68208

1 0