December 2023 - Wine-GitLab

Re: [PATCH v3 0/1] MR4578: include: Add Windows.Storage.Streams.InMemoryRandomAccessStream runtimeclass definition.
by Fabian Maurer (＠DarkShadow44) Dec. 5, 2023

Dec. 5, 2023

On Fri Dec 1 21:45:23 2023 +0000, Vijay Kiran Kamuju wrote: > According the idl its activatable, but I was not sure how to add the > activatable as its in hex > [activatable(0x06020000)] Probably just `activatable(Windows.Foundation.UniversalApiContract, 1.0)`. But I'm pretty sure you need that activatable if you want it to be usable later. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4578#note_54999

1 0

Re: [PATCH v8 0/1] MR3970: quartz/tests: Improve VMR9 ChangeD3DDevice test
by Alfred Agrell (＠Alcaro) Dec. 5, 2023

Dec. 5, 2023

On Tue Dec 5 01:21:52 2023 +0000, Zebediah Figura wrote: > I did some more digging on this one, and here is what my testing suggests: > * native ChangeD3DDevice() *just* reconnects the filter, i.e. it doesn't > directly call any of the same methods. > * This reconnection is done on a separate thread, for some reason. IPin > methods and IVMRSurfaceAllocator::TerminateDevice() are called from that thread. > * The filter graph documentation claims that IFilterGraph::Reconnect() > and IFilterGraph2::ReconnectEx() execute on a separate thread, but > according to my tests this is not true. > * ChangeD3DDevice() can be called while the filter is running, in which > case it will stop the graph, reconnnect, and then run. This is all done > on the same thread. Note that ReconnectEx() *cannot* be called while the > filter is running. > * ChangeD3DDevice() can be called while the filter is not connected. > * InitializeDevice() is not called immediately on connection. Rather, it > seems to be deferred until IMemAllocator::SetProperties(). > VFW_E_NOT_COMMITTED happens because reconnecting evidently decommits the > allocator, and we manage to race exactly such that the pins have been > disconnected but not yet reconnected when trying to send a frame. > As far as I can tell there is no actual way to synchronize this thread. > I suspect that in practice ChangeD3DDevice() is not expected to be > called while connected and stopped. I don't know if it's meant to be > called while disconnected or while running, or both. Either will avoid > this race, although ChangeD3DDevice() while running will definitely run > into other races surrounding state change (e.g. what happens if you > ChangeD3DDevice() and then decide to stop the graph?) > I think the only case we can really reliably test is the stopped case. I don't know what Microsoft's intention is or what's officially supported, but a quick WINEDEBUG=trace+quartz tells me that Kirikiri does, in fact, call ChangeD3DDevice while the graph is connected but stopped. It's the last thing it does before IMediaControl::Run(). (Kirikiri doesn't pause the graph, it just goes directly to Run.) Kirikiri's source code also shows that the function is called if IDirect3DDevice9::Present returns D3DERR_DEVICELOST, which only happens while paused or running, though I don't know if that code path was ever tested. (Also rebased this thing. No other changes.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_54997

1 0

[PATCH v10 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) Dec. 5, 2023

Dec. 5, 2023

Along with !4450, this fixes WMV videos in microkiri (https://bugs.winehq.org/show_bug.cgi?id=9127#c102) and Wagamama High Spec Trial Edition (https://wagahigh.com/download_trial.php#normal ; ダウンロード means download). -- v10: wmvcore/tests: Add tests for compressed output. winegstreamer: Implement compressed output support in WMSyncReader. winegstreamer: Leave pts/duration unchanged if they're not set. winegstreamer: Introduce mutex for wm_reader read_thread_shutdown. winegstreamer: Move file size to struct wm_reader. winegstreamer: Fill in a few more pieces of WMV format handling. winegstreamer: Add codec_data to WMVs. https://gitlab.winehq.org/wine/wine/-/merge_requests/4449

2 7

[PATCH v9 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) Dec. 5, 2023

Dec. 5, 2023

Along with !4450, this fixes WMV videos in microkiri (https://bugs.winehq.org/show_bug.cgi?id=9127#c102) and Wagamama High Spec Trial Edition (https://wagahigh.com/download_trial.php#normal ; ダウンロード means download). -- v9: wmvcore/tests: Add tests for compressed output. winegstreamer: Implement compressed output support in WMSyncReader. winegstreamer: Leave pts/duration unchanged if they're not set. winegstreamer: Introduce mutex for wm_reader read_thread_shutdown. winegstreamer: Move file size to struct wm_reader. winegstreamer: Fill in a few more pieces of WMV format handling. winegstreamer: Add codec_data to WMVs. https://gitlab.winehq.org/wine/wine/-/merge_requests/4449

4 18

Re: [PATCH v8 0/1] MR3970: quartz/tests: Improve VMR9 ChangeD3DDevice test
by Zebediah Figura (＠zfigura) Dec. 4, 2023

Dec. 4, 2023

I did some more digging on this one, and here is what my testing suggests: * native ChangeD3DDevice() *just* reconnects the filter, i.e. it doesn't directly call any of the same methods. * This reconnection is done on a separate thread, for some reason. IPin methods and IVMRSurfaceAllocator::TerminateDevice() are called from that thread. * The filter graph documentation claims that IFilterGraph::Reconnect() and IFilterGraph2::ReconnectEx() execute on a separate thread, but according to my tests this is not true. * ChangeD3DDevice() can be called while the filter is running, in which case it will stop the graph, reconnnect, and then run. This is all done on the same thread. Note that ReconnectEx() *cannot* be called while the filter is running. * ChangeD3DDevice() can be called while the filter is not connected. * InitializeDevice() is not called immediately on connection. Rather, it seems to be deferred until IMemAllocator::SetProperties(). VFW_E_NOT_COMMITTED happens because reconnecting evidently decommits the allocator, and we manage to race exactly such that the pins have been disconnected but not yet reconnected when trying to send a frame. As far as I can tell there is no actual way to synchronize this thread. I suspect that in practice ChangeD3DDevice() is not expected to be called while connected and stopped. I don't know if it's meant to be called while disconnected or while running, or both. Either will avoid this race, although ChangeD3DDevice() while running will definitely run into other races surrounding state change (e.g. what happens if you ChangeD3DDevice() and then decide to stop the graph?) I think the only case we can really reliably test is the stopped case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_54992

1 0

[PATCH 0/1] MR4598: po: Update Lithuanian translation.
by Aurimas Fišeras Dec. 4, 2023

Dec. 4, 2023

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

2 2

Re: [PATCH v4 0/2] MR4585: dsdmo: Add stubs for distortion and gargle effects - approved
by Alexandre Julliard (＠julliard) Dec. 4, 2023

Dec. 4, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4585

1 0

Re: [PATCH v7 0/1] MR4466: win32u/winex11: Add the GPU device physical memory registry - approved
by Alexandre Julliard (＠julliard) Dec. 4, 2023

Dec. 4, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4466

1 0

Re: [PATCH v2 0/2] MR4467: rpcrt4: Support for explicit handle passing - approved
by Alexandre Julliard (＠julliard) Dec. 4, 2023

Dec. 4, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4467

1 0

Re: [PATCH v2 0/2] MR4588: winegstreamer: Fix a memory leak (Coverity). - approved
by Alexandre Julliard (＠julliard) Dec. 4, 2023

Dec. 4, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4588

1 0