--
v3: uiautomationcore: Use EVENT_OBJECT_SHOW to advise providers of events being listened for in the COM API.
uiautomationcore: Separate checking if a node is within the scope of a registered event from event invocation.
uiautomationcore: Add support for passing WinEvents to the COM API.
uiautomationcore/tests: Add tests for COM event handler event advisement.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4005
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: d3d10/effect: Add support for 'or' instruction.
d3d10/effect: Add support for 'not' instruction.
d3d10/effect: Add support for 'exp' instruction.
d3d10/effect: Add support for 'log' instruction.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4007
Access to handle table is actually concurrent (and races / corrupts memory / crashes in practice when apps use different security contexts from different threads).
Then, unrelated to races, schan_handle_table can be reallocated and then schan_free_handles chain points to old memory location. Alternatively to patch 2, that could be fixed up on reallocating schan_handle_table, but it seems to me we can as well just scan the handle table for free slots.
--
v3:
https://gitlab.winehq.org/wine/wine/-/merge_requests/4008
This fixes a regression from 450c358881dbc6dcfb2692b8f4debb7db8fdc54b;
after testing for -Wl,-z,defs, CFLAGS was restored from an
incorrect variable, leaving CFLAGS essentially empty.
This would break builds for e.g. arm with Clang, where -mthumb would
be essential for being able to build some inline assembly snippets
correctly.
This also had the effect of dropping the default "-g -O2" arguments
from CFLAGS.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4013
--
v6: vkd3d-shader/dxil: Read the DXIL input and output signatures.
vkd3d-shader/dxil: Validate the entry point info.
vkd3d-shader/dxil: Read DXIL metadata named nodes.
vkd3d-shader/dxil: Read DXIL metadata kinds.
vkd3d-shader/dxil: Read DXIL metadata values.
vkd3d-shader/dxil: Read DXIL metadata nodes.
vkd3d-shader/dxil: Read DXIL metadata strings.
vkd3d-shader/dxil: Emit an error on allocation failure in dxil_record_to_string().
vkd3d-shader/dxil: Read global constants in sm6_parser_globals_init().
vkd3d-shader/dxil: Read immediate constant arrays.
tests/shader-runner: Test shaders with dxcompiler.
tests/shader-runner: Replace immediate shader type strings with an enum.
tests/shader-runner: Do not exit if a 'require' directive is not met.
tests/shader-runner: Handle individual keywords in shader directives.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/372
Access to handle table is actually concurrent (and races / corrupts memory / crashes in practice when apps use different security contexts from different threads).
Then, unrelated to races, schan_handle_table can be reallocated and then schan_free_handles chain points to old memory location. Alternatively to patch 2, that could be fixed up on reallocating schan_handle_table, but it seems to me we can as well just scan the handle table for free slots.
--
v2: secur32: Get rid of schannel free handle list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4008
Implements asin, acos, atan, and atan2.
Also includes some tests in a new test file.
One possible problem here is that I'm not sure how to test what Microsoft's atan and atan2 outputs are in boundary cases like atan2(1, 0). I've made the test suites adhere with the calculator program I've been using (Qalculate, which I assume is using libc's atan2).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55154
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/364
Access to handle table is actually concurrent (and races / corrupts memory / crashes in practice when apps use different security contexts from different threads).
Then, unrelated to races, schan_handle_table can be reallocated and then schan_free_handles chain points to old memory location. Alternatively to patch 2, that could be fixed up on reallocating schan_handle_table, but it seems to me we can as well just scan the handle table for free slots.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4008
---
I came across this in my attempts to implement nooverwrite maps based on
sysmem staging buffers when buffer storage is not available. My debug
modifications broke the fast path for update_sub_resource and the
wined3d_resource_wait() didn't do its job for the push constant buffers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3979
--
v2: uiautomationcore: Use EVENT_OBJECT_SHOW to advise providers of events being listened for in the COM API.
uiautomationcore: Separate checking if a node is within the scope of a registered event from event invocation.
uiautomationcore: Add support for passing WinEvents to a custom callback function.
uiautomationcore/tests: Add tests for COM event handler event advisement.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4005
--
v2: msvfw32: Use the debugstr_fourcc function instead of reimplementing it.
mscms: Use the debugstr_fourcc function instead of reimplementing it.
mciavi32: Use the debugstr_fourcc function instead of reimplementing it.
ddraw: Use the debugstr_fourcc function instead of reimplementing it.
comctl32: Use the debugstr_fourcc function instead of reimplementing it.
include: Introduce wine_dbgstr_fourcc and debugstr_fourcc.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3994
vkd3d-shader/tpf.c:3810:39: warning: passing argument 2 of ‘sm4_register_from_node’ from incompatible pointer type [-Wincompatible-pointer-types]
vkd3d-shader/tpf.c:4750:59: warning: passing argument 3 of ‘sm4_register_from_deref’ from incompatible pointer type [-Wincompatible-pointer-types]
The other option is to change the parameter to a DWORD but this is a larger change.
--
v3: vkd3d-shader: Fix compiler warning.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/385
On Tue Sep 26 23:38:34 2023 +0000, Alfred Agrell wrote:
> I don't know how many emails/etc gitlab sends, so I'm not sure if you
> saw it, but I implemented the entire thing; I think it's correct, but
> there's a fixme for the lack of tests (adding that is too far out of
> scope to belong in this MR).
> I could remove it if you don't want untested code floating around; now
> that I know what exactly it's trying to do, and what it's actually
> doing, it's not hard to work around it in the test instead.
I don't know whether this is correct or not, I think it'd be better to leave this aspect aside for now as like you said this is going a bit out of the scope of this MR.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47467
On Mon Oct 2 19:48:25 2023 +0000, Alfred Agrell wrote:
> mpegpsdemux is part of libgstmpegpsdemux.so. It's unrelated to ffmpeg,
> and it's present in Glorious-Eggroll already, nothing to do here.
> (However, it's absent from upstream Proton.)
> mpegvideoparse is in libgstvideoparsersbad.so. Likewise, this is part of
> GE but not Proton, and is not part of ffmpeg.
> avdec_mpeg2video is in libgstlibav.so, which is part of Proton - but the
> exact set of decoders it offers depends on which ffmpeg you have
> installed, and how it's configured.
> Did you rebuild ffmpeg and copy that into an existing Wine or Proton
> installation, without changing anything else? If yes, GStreamer probably
> didn't notice the update. `touch` libgstlibav.so, or delete your
> GStreamer plugin cache (probably at
> ~/.cache/gstreamer-1.0/registry.x86_64.bin or
> ~/steam/steamapps/compatdata/1234560/gstreamer-1.0/registry.x86_64.bin).
> You can also grep that registry file for avdec_mpeg2video: if that
> string is absent, then there's something wrong with your GStreamer or
> your ffmpeg, but if it does exist, the problem is on Wine's side
> (probably in this MR). (The cache is binary, but grep telling you
> whether the binary file matches is good enough.)
> Alternatively, I may simply be wrong; I've never compiled Proton, GE, or
> ffmpeg. Good call on trying mpeg2video; if it exists, it's probably
> better than plain mpegvideo.
We built proton-ge entirely, with as you can see in the previous link, the makefile where the gst and ffmpeg build parameters are set.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47447
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v4: d3d10/effect: Add support for 'dot' instruction.
d3d10/effect: Add support for 'floor' instruction.
d3d10/effect: Add support for 'ceil' instruction.
d3d10/tests: Compact returned arrays checks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3987
vkd3d-shader/tpf.c:3810:39: warning: passing argument 2 of ‘sm4_register_from_node’ from incompatible pointer type [-Wincompatible-pointer-types]
vkd3d-shader/tpf.c:4750:59: warning: passing argument 3 of ‘sm4_register_from_deref’ from incompatible pointer type [-Wincompatible-pointer-types]
The other option is to change the parameter to a DWORD but this is a larger change.
--
v2: vkd3d-shader: Fix compiler warning.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/385
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v3: d3d10/effect: Add support for 'dot' instruction.
d3d10/effect: Add support for 'floor' instruction.
d3d10/effect: Add support for 'ceil' instruction.
d3d10/tests: Compact returned arrays checks.
d3d10/effect: Add support for 'buge'/'bult' instructions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3987
On Mon Oct 2 19:06:41 2023 +0000, YuriK7 wrote:
> We tried to add the codec by adding
> --enable-decoder=mpegvideo,--enable-decoder=mpeg1video,--enable-decoder=mpeg2video
> and it still show the color bars... does it also need flags for the
> demuxer and parser in order to work ?
> In your gstkrkr code you say that "in GStreamer, decoding a mpeg video
> requires three elements: mpegpsdemux ! mpegvideoparse !
> avdec_mpeg2video" are those enabled by default if the ffmpeg flags are
> good ? We should enable them inside the GST_BAD_MESON_ARGS ?
> avdec_mpeg2video seems to be in the libav plugin.
> We made those changes to https://github.com/GloriousEggroll/proton-ge-custom/blob/master/Makefile.in
mpegpsdemux is part of libgstmpegpsdemux.so. It's unrelated to ffmpeg, and it's present in Glorious-Eggroll already, nothing to do here. (However, it's absent from upstream Proton.)
mpegvideoparse is in libgstvideoparsersbad.so. Likewise, this is part of GE but not Proton, and is not part of ffmpeg.
avdec_mpeg2video is in libgstlibav.so, which is part of Proton - but the exact set of decoders it offers depends on which ffmpeg you have installed, and how it's configured.
Did you rebuild ffmpeg and copy that into an existing Wine or Proton installation, without changing anything else? If yes, GStreamer probably didn't notice the update. `touch` libgstlibav.so, or delete your GStreamer plugin cache (probably at ~/.cache/gstreamer-1.0/registry.x86_64.bin or ~/steam/steamapps/compatdata/1234560/gstreamer-1.0/registry.x86_64.bin). You can also grep that registry file for avdec_mpeg2video: if that string is absent, then there's something wrong with your GStreamer or your ffmpeg, but if it does exist, the problem is on Wine's side (probably in this MR). (The cache is binary, but grep telling you whether the binary file matches is good enough.)
Alternatively, I may simply be wrong; I've never compiled Proton, GE, or ffmpeg. Good call on trying mpeg2video; if it exists, it's probably better than plain mpegvideo.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47409
On Sun Oct 1 23:56:05 2023 +0000, Alfred Agrell wrote:
> Yes, that is consistent with my experience. I tried Azumanga (everything
> looks good to me with this patch) and Touhou (crashes on Wine 8.17, Wine
> 8.17 with this patch, and Debian's Wine 8.0; different output before the
> crash, but they all segfault in
> SampleGrabber_ISampleGrabber_GetCurrentBuffer). Sounds like a different
> bug to me.
> The color bars are not a Wine bug; they're protonmediaconverter. It does
> that if it can't find a converted version of the media, which it can't
> if you're running it outside Steam. gstkrkr fills that exact hole.
> (gstkrkr also does a little trick to ensure ffmpeg's WMA audio decoder
> is selected instead of mediaconverter.)
We tried to add the codec by adding --enable-decoder=mpegvideo,--enable-decoder=mpeg1video,--enable-decoder=mpeg2video and it still show the color bars... does it also need flags for the demuxer and parser in order to work ?
In your gstkrkr code you say that "in GStreamer, decoding a mpeg video requires three elements: mpegpsdemux ! mpegvideoparse ! avdec_mpeg2video" are those enabled by default if the ffmpeg flags are good ? We should enable them inside the GST_BAD_MESON_ARGS ? avdec_mpeg2video seems to be in the libav plugin.
We made those changes to https://github.com/GloriousEggroll/proton-ge-custom/blob/master/Makefile.in
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47406
--
v2: dmime: Introduce a new segment_state_create constructor.
dmime: Redirect IDirectMusicPerformance_PlaySegment to PlaySegmentEx.
dmime: Implement some segment state default values.
dmime: Get rid of the IDirectMusicSegmentState8Impl typedef.
dmime: Rename DirectMusicSegmentState8 method prefix to segment_state.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3995
On Mon Oct 2 18:16:53 2023 +0000, David McFarland wrote:
> comment fixed.
> > It would be nice if at least the lower bound could be read from the
> native audio system, though I don't know how to do that
> I like this idea, but I'm not sure how to pull it off either. I guess
> the biggest downside to this implementation would be unnecessarily high latency?
> My preference would be to leave that for a separate MR.
I'm going to resolve this. Feel free to reopen if it's blocking.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3554#note_47399
Called by Roon.
I have more patches for this, but I split them up for easier review.
--
v2: windows.media.mediacontrol: Implement some ISystemMediaTransportControls properties.
windows.media.mediacontrol/tests: Add some ISystemMediaTransportControls properties tests.
windows.media.mediacontrol: Implement ISystemMediaTransportControlsInterop::GetForWindow().
windows.media.mediacontrol/tests: Add ISystemMediaTransportControlsInterop::GetForWindow() tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3993
--
v3: uiautomationcore: Add support for raising events passed to our IProxyProviderWinEventSink interface.
uiautomationcore: Pass WinEvent data to IProxyProviderWinEventHandler::RespondToWinEvent.
uiautomationcore: Add support for marking the root IAccessible as known on non-root IAccessibles upon proxy provider creation.
uiautomationcore: Add support for ignoring ProviderOptions_UseComThreading when creating an HUIANODE.
uiautomationcore: Create HUIANODE for WinEvents that should invoke IProxyProviderWinEventHandler::RespondToWinEvent.
uiautomationcore: Check if we should try to invoke IProxyProviderWinEventHandler::RespondToWinEvent for registered UIA events.
uiautomationcore: Introduce uia_event_for_each function for iterating through registered events.
uiautomationcore/tests: Add another test for IProxyProviderWinEventHandler child HWND scope checking.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3956
Manually disable some warnings that are currently emitted. Eventually
the warnings should be solved and -Werror should remain alone.
--
v7: ci: Update the README with some recent changes.
demos: Do not trigger -Wmissing-prototypes for wmain().
vkd3d: Use CONST_VTABLE.
ci: Store config.log as a build artifact.
ci: Compile with -Werror.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/377
Manually disable some warnings that are currently emitted. Eventually
the warnings should be solved and -Werror should remain alone.
--
v5: ci: Update the README with some recent changes.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/377
vkd3d-shader/tpf.c:3810:39: warning: passing argument 2 of ‘sm4_register_from_node’ from incompatible pointer type [-Wincompatible-pointer-types]
vkd3d-shader/tpf.c:4750:59: warning: passing argument 3 of ‘sm4_register_from_deref’ from incompatible pointer type [-Wincompatible-pointer-types]
The other option is to change the parameter to a DWORD but this is a larger change.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/385
Yes, currently MCI_MapMsgAtoW returns a tri-state.
-1 = Memory allocation error
0 = No unmap required
1 = Unmap required.
Since MCI_UnmapMsgAtoW handles all the cases where MCI_MapMsgAtoW allocates memory. Why not just
call MCI_UnmapMsgAtoW to do its thing in all cases?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3854#note_47342
On Sun Oct 1 23:30:07 2023 +0000, YuriK7 wrote:
> Thanks !
> The game I mentioned (touhou sky fight) is a weird case. It already
> hangs (actually it just errors out and closes) without your patch on
> vanilla wine whit the gstreamer shipped with wine-ge 8-16 where they
> updated it to 1.22. With the old gstreamer it used to be a skippable
> black screen, however adding gstkrkr makes it crash. This merge doesn't
> seem to change anything on that so be reassured, I guess I should open
> either a wine issue or a gstreamer issue...
> But Azumanga Fighter, Higurashi Daybreak Kai and HaruToma 2 works
> perfectly well with the new gstreamer + gstkrkr (the new version show a
> color bars screen when the codec is missing, instead of playing the sound).
Yes, that is consistent with my experience. I tried Azumanga (everything looks good to me with this patch) and Touhou (crashes on Wine 8.17, Wine 8.17 with this patch, and Debian's Wine 8.0; different output before the crash, but they all segfault in SampleGrabber_ISampleGrabber_GetCurrentBuffer). Sounds like a different bug to me.
The color bars are not a Wine bug; they're protonmediaconverter. It does that if it can't find a converted version of the media, which it can't if you're running it outside Steam. gstkrkr fills that exact hole. (gstkrkr also does a little trick to ensure ffmpeg's WMA audio decoder is selected instead of mediaconverter.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47318
On Sun Oct 1 14:18:55 2023 +0000, Alfred Agrell wrote:
> Glorious-Eggroll has a MPEG demuxer, which Proton's GStreamer lacks, but
> neither of them have any MPEG-1 video decoder.
> From what I can google, the correct incantation is adding
> --enable-decoder=mpegvideo to GE's ffmpeg configure line; if successful,
> it should show up in GStreamer as avdec_mpeg2video.
> If adding gstkrkr works even without this MR, my guess is that those
> programs tell DirectShow to automatically pick the appropriate decoders,
> which ends up using CLSID_decodebin_parser instead of
> CLSID_CMpegVideoCodec; you were missing the codec, but nothing else.
> If adding this MR makes it hang or otherwise screw up, that's definitely
> something I should look into...
Thanks !
The game I mentioned (touhou sky fight) is a weird case. It already hangs (actually it just errors out and closes) without your patch on vanilla wine whit the gstreamer shipped with wine-ge 8-16 where they updated it to 1.22. With the old gstreamer it used to be a skippable black screen, however adding gstkrkr makes it crash. This merge doesn't seem to change anything on that so be reassured, I guess I should open either a wine issue or a gstreamer issue...
But Azumanga Fighter, Higurashi Daybreak Kai and HaruToma 2 works perfectly well with the new gstreamer + gstkrkr (the new version show a color bars screen when the codec is missing, instead of playing the sound).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47317
--
v3: ntdll: Add support for FILE_{RENAME,LINK}_POSIX_SEMANTICS.
ntdll: Factored out get_inode_open_sharing.
ntdll/test: Add tests for FILE_LINK_POSIX_SEMANTICS.
ntdll/test: Add tests for FILE_RENAME_POSIX_SEMANTICS.
ntdll: Add support for FILE_{RENAME,LINK}_IGNORE_READONLY_ATTRIBUTE.
server: Don't allow read-only files to be replaced by File{Rename,Link}Information{,Ex}.
ntdll/test: Add tests for FILE_LINK_IGNORE_READONLY_ATTRIBUTE.
ntdll/test: Add tests for FILE_RENAME_IGNORE_READONLY_ATTRIBUTE.
ntdll/test: Use FileDispositionInformationEx to delete files and directories.
ntdll: Initial implementation of FileLinkInformationEx.
ntdll: Initial implementation of FileRenameInformationEx.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3907
On Sun Oct 1 13:54:50 2023 +0000, YuriK7 wrote:
> Adding the gstkrkr .so files does indeed fix the issue even without this
> merge an azumanga fighter and HaruToma 2. It didn't worked with touhou
> sky fight but I couldn't test with your merge as it hangs with vanilla wine.
> I thought wine-ge had all the plugins, as I used their libs to get rid
> of the missing MPEG1 decoder issue. Do you know exactly which
> plugin/part/flag they have to add ?
Glorious-Eggroll has a MPEG demuxer, which Proton's GStreamer lacks, but neither of them have any MPEG-1 video decoder.
From what I can google, the correct incantation is adding --enable-decoder=mpegvideo to GE's ffmpeg configure line; if successful, it should show up in GStreamer as avdec_mpeg2video.
If adding gstkrkr works even without this MR, my guess is that those programs tell DirectShow to automatically pick the appropriate decoders, which ends up using CLSID_decodebin_parser instead of CLSID_CMpegVideoCodec; you were missing the codec, but nothing else.
If adding this MR makes it hang or otherwise screw up, that's definitely something I should look into...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47297
On Sun Oct 1 13:54:50 2023 +0000, Alfred Agrell wrote:
> Yep, that one looks like a close relative of
> https://bugs.winehq.org/show_bug.cgi?id=9127 (possibly even duplicate).
> Last time I checked, Proton-GE didn't include any MPEG video decoder.
> Probably because it's unnecessary - without Wine-side support, there's
> no way to access that codec, so there's no point wasting space on it.
> Once this thing is merged, that will become a bug on their end. Feel
> free to report it.
> If you want a faster solution, you can take the GStreamer plugin from
> https://github.com/Alcaro/krkrwine/releases/tag/v1.0.0 and place it in
> the GST_PLUGIN_SYSTEM_PATH. (I wouldn't recommend installing the rest of
> that program, it's tested with Proton 8.0 only and may interact weirdly
> with this MR.)
Adding the gstkrkr .so files does indeed fix the issue even without this merge an azumanga fighter and HaruToma 2. It didn't worked with touhou sky fight but I couldn't test with your merge as it hangs with vanilla wine.
I thought wine-ge had all the plugins, as I used their libs to get rid of the missing MPEG1 decoder issue. Do you know exactly which plugin/part/flag they have to add ?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47296
Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v6: quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Implement a little more of IAMStreamSelect in CLSID_MPEG1Splitter.
winegstreamer: Handle format changes better in Quartz.
winegstreamer: Implement CLSID_CMpegVideoCodec.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938