Marked as WIP since it depends on !8175 for the test to run reliably (and currently includes its commits).
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
v3: mfsrcsnk: Support thinning.
winedmo: Support thinning.
winegstreamer: Support thinning in media source.
winegstreamer: Support thinning in wg_parser.
mf: Support thinning in media session.
mf/tests: Add tests for thinning.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8184
Over the past several weeks I've been working on and off on this. I didn't track the hours but I'm sure that I've spent 80+ hours on the feature. I've tested and retested all known scenarios and it seems to be working as expected.
--
v55: cmd: Implement tab completion for command line entry.
include: Fix mistitled field in CONSOLE_READCONSOLE_CONTROL.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843
Marked as WIP since it depends on !8175 for the test to run reliably (and currently includes its commits).
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
v2: mfsrcsnk: Support thinning.
winedmo: Support thinning.
winegstreamer: Support thinning in media source.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8184
Marked as WIP since it depends on !8175 for the test to run reliably (and currently includes its commits).
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8184
I'm dealing with a game that relies on this constant.
Tagging @rbernon since this is using a proton commit of his.
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8183
Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively.
This MR introduces initial support for accessing GATT services on LE devices:
* Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them.
* Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately.
* Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices.
* Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs.
* Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices).
--
v3: bluetoothapis/tests: Add tests for BluetoothGATTGetServices.
bluetoothapis: Implement BluetoothGATTGetServices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8174
At the end of LIST_FOR_EACH_ENTRY, assuming no matches are found, `provider` will point to the list
head, not NULL, as a result we call IsEqualGUID on invalid memory.
--
v2: crypt32: Fix invalid access of list head.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8179
I was able to replicate the issue seen in [Bug 58113](https://bugs.winehq.org/show_bug.cgi?id=58113) on my M1.
The issue stems from the usage of AudioDevicePropertyVolumeScalar, which the audio driver for the M1 does not support (at least so it appears.) Using AudioObjectIsPropertySettable allows for fast checking for this situation, including preemptively disabling main channel audio if it appears to be unsupported.
--
v4: winecoreaudio: quality improvements
Revert "winecoreaudio: Implement per-channel volume control."
https://gitlab.winehq.org/wine/wine/-/merge_requests/7920
@alexhenrie @zhiyi
Description:
When flags does not include DT_CALCRECT, since len is calculated in the middle,
it will be reduced to zero. Resulting in the length of the processed string that
is finally returned to zero and the non-processing string length is unchanged.
But some application taking the non-processing string length to zero as the loop
end condition.
The test case's merge request number is 8177.
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8178
@alexhenrie @zhiyi
The corresponding Windows test demo is as follows:
[test_DrawTextExW.exe](/uploads/ff1eafc9c58ac03b598699a93136484c/test_DrawTextExW.exe)
[test_DrawTextExW.c](/uploads/a41719a33c2ee0e057c911933bf55180/test_DrawTextExW.c)
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: I64052ba8aa8161ad83c1811d642aedbe462ef5ea
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8177
This is required to fix video playback in Crashlands 2 on Proton 10.
--
v2: mfreadwrite: Fix media type output when video processor is used.
mfreadwrite/tests: Check DEFAULT_STRIDE is not always present.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8172
I was able to replicate the issue seen in [Bug 58113](https://bugs.winehq.org/show_bug.cgi?id=58113) on my M1.
The issue stems from the usage of AudioDevicePropertyVolumeScalar, which the audio driver for the M1 does not support (at least so it appears.) Using AudioObjectIsPropertySettable allows for fast checking for this situation, including preemptively disabling main channel audio if it appears to be unsupported.
--
v3: winecoreaudio: Fixed outdated params, improvements
Revert "winecoreaudio: Implement per-channel volume control."
https://gitlab.winehq.org/wine/wine/-/merge_requests/7920
On Tue Apr 22 19:17:10 2025 +0000, Kevin Puetz wrote:
> Yes, but not as rebased to master (we're quite a bit behind, so I just
> ran things through testbot.winehq.org before submitting rather than
> doing a full local build of 10.6). I'll mark as draft for now and do
> some more testing...
Ok, my apologies that this took so long to get back to. The fix was sound, but the test was completely flawed and I'm not sure how it seemed to work the first time. The key problem is that, since the whole scenario involves a hostapartment, the class factory will be a proxy. And to keep cross-thread traffic down, proxies keep their own refcount, with the proxy owning a single refcount to the stub, which owns a single refcount to the real implementing object. So observing the refcount of the proxy could never have shown whether the actual implementation had been leaked.
So now the test instead checks the way we observed the problem in real life - we put a "real" CLSID in to testlib.dll, and notice that the existence of any external refcounts on the class factory object has caused testlib.dll's DllCanUnloadNow to return S_FALSE.
So now the compobj test I added seems OK
ole32:compobj start dlls/ole32/tests/compobj.c
ole32:compobj:0c0c done (0) in 2s 1498B
However, pipeline is still showing VM failure on mac
> no IP address found, is your VM running
And a failure on linux-32, not in the test I changed:
> ole32:clipboard:0bf8 done (0) in 0s 5076B
> ole32:compobj start dlls/ole32/tests/compobj.c
which is where my new test is - the failure is later
> ole32:marshal start dlls/ole32/tests/marshal.c
> marshal.c:4214:0.026 Test failed: got 0
> marshal.c:4223:0.027 Test failed: Number of locks should be 0, but actually is 2
These marshal.c failures seem to be present in other PRs too (including ones that merged last night), so I assume they are unrelated...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7880#note_104932