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`
--
v6: shell32: Restore the ability of running native unix programs with ShellExecute
https://gitlab.winehq.org/wine/wine/-/merge_requests/5400
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!
--
v2: winex11.drv: Remove unnecessary parameter from describe_pixel_format.
winex11.drv: Enable wglDescribePixelFormat through p_get_pixel_formats.
winewayland.drv: Enable wglDescribePixelFormat through p_get_pixel_formats.
opengl32: Cache driver pixel format information.
opengl32: Implement wglDescribePixelFormat using new driver API get_pixel_formats.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5517
In source_reader_create_transform(), store the result of
IMFActivate_ActivateObject() so that in the event of failure, resources
are freed and an appropriate HRESULT is returned.
Previously, if every object's activation failed, the last part of the
function was not aware of this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5515
The default behaviour for gstreamer is to use the URI to create the
stream-id. Without this, gstreamer creates a random stream-id per pad
which can cause inconsistent ordering on the decodebin src pads.
This in turn can cause issues, for example, with audio stream selection.
The first commit is a partial cherry-pick of eda34f74c6ad from Proton.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5511
On Mon Apr 22 09:02:12 2024 +0000, Alexandros Frantzis wrote:
> 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?
Yeah, may be some mix up about who can approve it for the final merge. See [here](https://gitlab.winehq.org/wine/wine/-/merge_requests/5178#note_65890)
> It's perhaps instead that approval only show up if the person is assigned as a reviewer, or that it was overlooked.
It would be good to merge it for the next release.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5178#note_68466
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
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
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
> > > 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
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
> 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
Overriding the SDL_VIDEODRIVER variable (for Wayland support as an example)
on the Linux side can lead to some games under Wine failing to load (so treat
that variable as special).
--
v3: ntdll: Add SDL_AUDIO*/SDL_VIDEO* to the special variables list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5231
> At the same time, I haven't seen any evidence that a modern GPU will ever perform better with a vertex buffer not in sysmem unless it's using the streaming pattern
I guess it should perform better with a vidmem buffer if the buffer is holding static data and not locked after the initial upload.
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)
Conceptually the two patches have my blessing though, regardless of specifics of what PoP3D is doing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2404#note_68141
On Thu Apr 18 23:08:03 2024 +0000, Jinoh Kang wrote:
> @rbernon Thanks for your review! Right now I'm tentatively putting this
> MR on hold until I find a solution for a memory leak: a new (redundant)
> dependency edge is added every time the application calls
> `GetProcAddress()` on a forwarded ref.
Has the memory leak been fixed? 🫗️
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7#note_68140
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2404#note_68109