On Mon Mar 3 06:33:06 2025 +0000, Dmitry Timoshkov wrote:
> The tests don't pass with existing code.
It looks like you are right, new tests actually pass with current implementation. Although the patch makes support for WICBitmapTransformRotate270 more explicit I'm not opposed to leave the code intact. I'm open to suggestions.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7459#note_96507
On Mon Mar 3 06:33:06 2025 +0000, Elizabeth Figura wrote:
> Wait, isn't this already implemented? WICBitmapTransformRotate270 is the
> bitwise OR of 90 and 180, and the code seems to take that into account,
> am I missing something?
The tests don't pass with existing code.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7459#note_96498
This fixes failure to play the prologue video in Planet of the Apes: Last Frontier, which unpauses by calling Start() with a location. The exact state leading to this issue does not occur in the Start() tests, and it's not clear how to reproduce it reliably.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7466
On Sat Mar 1 21:59:13 2025 +0000, Brendan McGrath wrote:
> I took a look at the linux-32 results, but I missed the mf failures (I
> thought they were all ddraw). Why would linux-32 fail but not linux-64?
> Anyway, it's the same test failing twice:
> ```
> $ xmllint --xpath 'testsuites/testsuite/testcase[failure and
> @classname="mf:transform"]/@name' winetest.xml
> name="mf:transform transform.c:2587 Test failed: aacdec:
> "MF_MT_USER_DATA": SetInputType returned 0."
> name="mf:transform transform.c:2587 Test failed: aacdec:
> "MF_MT_USER_DATA": SetInputType returned 0."
> ```
> The test checks that a call to `SetInputType` on the AAC decoder returns
> an error when `MF_MT_USER_DATA` is missing. It does so by relying on the
> return value of `MFCreateWaveFormatExFromMFMediaType`. So it's dependent
> on what was the broken behavior. I suspect it should also be checking
> `cbSize`. I'll add tests to confirm as much and then fix.
> Note, I have confirmed that we now have the correct behavior for
> `MFCreateWaveFormatExFromMFMediaType` by adding (locally) the following
> two tests:
> ```
> @@ -5958,6 +5958,8 @@ static void test_MFCreateWaveFormatExFromMFMediaType(void)
> { &MFAudioFormat_Float, WAVE_FORMAT_IEEE_FLOAT,
> sizeof(WAVEFORMATEX), 0, },
> { &MFAudioFormat_MP3, WAVE_FORMAT_MPEGLAYER3,
> sizeof(WAVEFORMATEX), 0, },
> { &DUMMY_GUID3, WAVE_FORMAT_EXTENSIBLE,
> sizeof(WAVEFORMATEXTENSIBLE), 22, },
> + { &MFAudioFormat_AAC, WAVE_FORMAT_MPEG_HEAAC,
> sizeof(WAVEFORMATEX), 0, },
> + { &MFAudioFormat_RAW_AAC, WAVE_FORMAT_RAW_AAC1,
> sizeof(WAVEFORMATEX), 0, },
> ```
> Test bot passes:
> https://testbot.winehq.org/JobDetails.pl?Key=151559
> Well Windows did, Debian crashed.
I've raised MR !7465 to fix the failing test. I also add new tests that seem to indicate we are still missing some validation in the aac decoder around `MF_MT_USER_DATA`. For example, in one of the tests, I send a value of 44.1KHz in `MF_MT_AUDIO_SAMPLES_PER_SECOND`, but a value of 48KHz in `MF_MT_USER_DATA`. Windows returns `MF_E_INVALIDMEDIATYPE`, but we return `S_OK`. So this test is currently marked as todo.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7417#note_96490
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: windowscodecs: Implement GetPreferredVendorGUID().
windowscodecs/metadata: Implement GetClassID().
windowscodecs/tests: Add some tests for metadata handler GetClassID().
windowscodecs/metadata: Replicate original stream position when creating writer instances from readers.
windowscodecs/metadata: Restore original stream position on GetStream().
windowscodecs/tests: Add some tests for stream position handling when nested readers are used.
windowscodecs: Implement CreateQueryWriterFromReader().
windowscodecs/metadata: Do not decorate 'wstr' items with a type name in returned queries.
windowscodecs/tests: Add some more tests for query enumeration.
windowscodecs: Implement query strings enumerator.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7407
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v3: d2d1: Update DC target surface with current HDC contents on BeginDraw().
d2d1/tests: Add some tests for device context handling in the DC target.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7443
There is no ([not yet?](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requ…) dedicated protocol for requesting pointer warps, but it's possible to request one with `zwp_locked_pointer_v1.set_cursor_position_hint` which may be performed when the pointer is unlocked. The idea is to quickly lock/set position/unlock. This is used by SDL (in some cases: [SDL_MOUSE_EMULATE_WARP_WITH_RELATIVE](https://wiki.libsdl.org/SDL3/SDL_HINT…) and Xwayland. The limitation is/will be that the compositor will ignore requests to warp the pointer outside of surface bounds.
What I'd like to have working is the auto cursor placement feature of some applications, where they just want to call SetCursorPos towards specific UI elements inside their single window, and usually they'll be unclipped and have a visible cursor while doing this.
This patch also happens to allow mouselook to work in applications which use SetCursorPos for mouselook and aren't getting covered by the heuristics that turn on Wayland relative motion (for some reason the driver thinks the cursor is visible). Seems to affect Half-Life (GoldSrc) on my system. Though force enabling relative motion with an environment variable in a custom build or somehow improving the heuristics will also fix that.
~~A suface/pointer can only have one lock or confinement, and this implementation depends on the pointer lock. So if needed, I temporarily unlock/unconfine in order to do the warp then relock/reconfine. I modified `wayland_pointer_update_constraint` so I don't have to temporarily disable relative motion during this in case it's enabled. I think it's safe/a no-op to attempt pointer warps while using relative motion, as according to the protocol the warp will not generate a relative motion event, and while there will be a wl_pointer motion event, they're ignored while relative motion is being used.~~
--
v5: winewayland: Implement SetCursorPos via pointer lock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7353
Having a pointer lock implies that relative motion is also used. When
refocusing on a mouselook application which the driver is using relative
motion for, an absolute motion hardware input is sent because of
handling the wl_pointer.enter event. This can result in an unwanted
warp/jerk.
The need to handle enter motion isn't applicable to mouselook or cases
where the pointer is locked because the application is drawing its own
cursor while covering vscreen, so it can be ignored during pointer lock.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7457
On Sat Mar 1 10:14:45 2025 +0000, Nikolay Sivov wrote:
> Sorry, I didn't check linux-32 results.
I took a look at the linux-32 results, but I missed the mf failures (I thought they were all ddraw). Why would linux-32 fail but not linux-64?
Anyway, it's the same test failing twice:
```
$ xmllint --xpath 'testsuites/testsuite/testcase[failure and @classname="mf:transform"]/@name' winetest.xml
name="mf:transform transform.c:2587 Test failed: aacdec: "MF_MT_USER_DATA": SetInputType returned 0."
name="mf:transform transform.c:2587 Test failed: aacdec: "MF_MT_USER_DATA": SetInputType returned 0."
```
The test checks that a call to `SetInputType` on the AAC decoder returns an error when `MF_MT_USER_DATA` is missing. It does so by relying on the return value of `MFCreateWaveFormatExFromMFMediaType`. So it's dependent on what was the broken behavior. I suspect it should also be checking `cbSize`. I'll add tests to confirm as much and then fix.
Note, I have confirmed that we now have the correct behavior for `MFCreateWaveFormatExFromMFMediaType` by adding (locally) the following two tests:
```
@@ -5958,6 +5958,8 @@ static void test_MFCreateWaveFormatExFromMFMediaType(void)
{ &MFAudioFormat_Float, WAVE_FORMAT_IEEE_FLOAT, sizeof(WAVEFORMATEX), 0, },
{ &MFAudioFormat_MP3, WAVE_FORMAT_MPEGLAYER3, sizeof(WAVEFORMATEX), 0, },
{ &DUMMY_GUID3, WAVE_FORMAT_EXTENSIBLE, sizeof(WAVEFORMATEXTENSIBLE), 22, },
+ { &MFAudioFormat_AAC, WAVE_FORMAT_MPEG_HEAAC, sizeof(WAVEFORMATEX), 0, },
+ { &MFAudioFormat_RAW_AAC, WAVE_FORMAT_RAW_AAC1, sizeof(WAVEFORMATEX), 0, },
```
Test bot passes:
https://testbot.winehq.org/JobDetails.pl?Key=151559
Well Windows did, Debian crashed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7417#note_96328