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
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
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