--
v2: winepulse: Ensure unixlib function tables and enum stay in sync.
wineoss: Ensure unixlib function tables and enum stay in sync.
winecoreaudio: Ensure unixlib function tables and enum stay in sync.
winealsa: Ensure unixlib function tables and enum stay in sync.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3848
With recent changes leave_handler writes to some of its parameter's
fields (via DS_sig and ES_sig) on FreeBSD and NetBSD - which fails
since it is declared const. Accordingly strip const-ness.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3845
...nope, my VM no longer works. I'm just getting nonsensical errors (why would IVMRSurfaceAllocatorNotify9_SetD3DDevice return E_NOINTERFACE), even from programs that worked last time I tried. I'd suspect some broken update somewhere, GPU stuff has always been finicky in VMs.
I'd be happy to fix this test if I could, but without access to a functional Windows installation, there's not much I can do :/
Though I have done some manual testing with some real-world programs, so I'm confident that it's better than the previous stub, at least.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3792#note_45450
> HLSL_IR_STORE and HLSL_IR_RESOURCE_STORE exist though. I don't think you can use those as HLSL_IR_EXPR sources (right?), but that might not necessarily be obvious.
As this MR proves, we're not in an overabundance of documentation about the HLSL IR, that's sure.
In my interpretation, the fact that `HLSL_IR_STORE` and `HLSL_IR_RESOURCE_STORE` don't evaluate to a value is of little relevance. Even if they did, they are executed if the control flow reach them, not if their result is used.
I realize that my sentence "Nodes purely forward a value and have no side effects" has probably a poor choice of words: of course nodes, which we use essentially as a synonym for "instructions", of course do have side effects (in general, at least). What I wanted to say is probably more like "References purely forward a value [etc]": the act of recalling the value produced by an earlier node/instruction has no side effect, therefore the question if `MOVC` evaluates the operand which is not selected is empty: the operand doesn't bear any side effect, be it selected or not; and the referenced node/instruction is evaluated (possibly with side effects) independently of its value being selected by `MOVC` or not, simply by virtue of being in the control flow; it would have been evaluated even if `MOVC` didn't have it as an operand at all.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/340#note_45445
Now that we can write HLSL intrinsics in HLSL, cleaning up missing
functions becomes much easier.
This commit also extends the trigonometry tests a little bit to make
sure that tan works right.
--
v5: vkd3d-shader/hlsl: Implement intrinsic tan.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/321
> Without codec_data set, mp4mux element fails. And according to my test, setting codec_data to MF_MT_MPEG_SEQUENCE_HEADER is OK, becuase I finally successfully generate a mp4 file which is able to be played by video player.
Yeah, but mp4mux also requires stream-format=avc(3). That's not a coincidence; besides the difference in start codes I mentioned in 3810, the Annex B and AVC formats differ in whether the "codec data" is contained in-band or out-of-band (Annex B has it in-band; AVC has it out-of-band). If you use h264parse to convert Annex B to AVC, it should also supply the correct codec data.
I can't explain why the file gets played back correctly in that case—perhaps GStreamer (or whatever player you're using) detects that the data is actually in the Annex B format and plays it back as such, ignoring the incorrect out-of-band codec data?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636#note_45360
...actually, it seems that there are at least two bugs nearby. That segfault hits if IVMRSurfaceAllocatorNotify9_SetD3DDevice fails - but if it succeeds (it does on w1121H2_newtb-w11pro64-amd-64 and w1121H2_newtb-w11pro64-nv-64), native Quartz does something different from what I implemented.
Unfortunately, trying to run that test on my w10 VM returns
vmr9.c:2788: Tests skipped: Direct3D does not support video rendering.
vmr9.c:3229: Tests skipped: Direct3D does not support video rendering.
vmr9.c:4042: Tests skipped: Got E_FAIL when setting allocator properties.
vmr9.c:4365: Tests skipped: Direct3D does not support video rendering.
0a60:vmr9: 2944 tests executed (0 marked as todo, 0 as flaky, 0 failures), 4 skipped.
and I'd rather not try to fix that thing via guesswork against your CI system, that's a waste of resources.
Some of my test programs can run VMR9 just fine in that VM, so I guess I'll rewrite that test from scratch and see if I can create a more reliable test...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3792#note_45346
kwin resizes hidden windows most of the time. I see the existing flaky markers triggered on Windows 11 occasionally. This MR makes the ddraw-d3d9 tests run reliably on kwin (I tested version 5.27.7) in Xephyr and a real display.
This makes the !WS_VISIBLE tests fairly weak since we ignore the random failures we get on Windows and Wine.
According to https://marc.info/?l=wine-patches&m=141642450913299&w=2 , the mail to wine-patches behind commit f4d520d6e2, which added this test, those tests intended to cover some differences between d3d9 and d3d9ex, not a specific game behavior. I vaguely remember that I did run into something that needed this behavior, but I can't find out any more what this might have been. The memory of those 9 year old patches is getting blurry.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3779
This series fixes a few bugs in the d3d tests that cause them to crash on my Windows XP laptop with the r200 GPU (dx8 era).
There are plenty more problems on this GPU on Windows. d3d8:visual hangs the entire system. d3d9:device has some failing tests. d3d9:visual crashes, which is probably good because otherwise it would also cause a kernel panic.
--
v2: d3d9/tests: Fix skipping ATI2N in test_resource_access.
d3d8/tests: Fix skipping ATI2N in test_resource_access.
d3d9/tests: Request a 3 mip level cube texture in test_getdc().
d3d8/tests: Zero stride tests crash on Windows XP, r200 GPU.
d3d9/tests: Zero stride tests crash on Windows XP, r200 GPU.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3757
On Thu Sep 14 07:06:18 2023 +0000, Ziqing Hui wrote:
> This was added because mp4mux is requiring it: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/…
> Without codec_data set, mp4mux element fails. And according to my test,
> setting codec_data to MF_MT_MPEG_SEQUENCE_HEADER is OK, becuase I
> finally successfully generate a mp4 file which is able to be played by
> video player.
I didn't dig into how mp4mux element handle h264 codec_data. But the truth is it do accpet MF_MT_MPEG_SEQUENCE_HEADER.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636#note_45304
On Thu Sep 14 07:06:18 2023 +0000, Zebediah Figura wrote:
> Hi Ziqing, I've been doing some research, and I believe patch 2/6
> (committed as 320383c594c4) is incorrect. GStreamer's "codec-data" field
> is an AVCDecoderConfigurationRecord, as defined by ISO/IEC 14496-15
> (which you can see at [1]). MF_MT_MPEG_SEQUENCE_HEADER, on the other
> hand, seems to contain the raw SPS/PPS NALUs, start codes and all.
> Since Microsoft uses Annex B everywhere, it shouldn't need the
> codec-data anyway, so I'm curious now why this was added—was there a
> need for it, or did you just add it on the assumption that the two
> attributes mapped to each other?
> [1] https://doc-kurento.readthedocs.io/en/latest/knowledge/h264.html#gstreamer-…
This was added because mp4mux is requiring it: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/…
Without codec_data set, mp4mux element fails. And according to my test, setting codec_data to MF_MT_MPEG_SEQUENCE_HEADER is OK, becuase I finally successfully generate a mp4 file which is able to be played by video player.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636#note_45303
On Thu Aug 31 18:29:16 2023 +0000, Matteo Bruni wrote:
> That's 100% it :rolling_eyes:
> But yeah, that's what I mean when I say that d3d QXL test results ought
> to be ignored.
That sounds like a bug in QXL. Is there a QEmu bug report for this issue?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3694#note_45290
Hi Ziqing, I've been doing some research, and I believe patch 2/6 (committed as 320383c594c4) is incorrect. GStreamer's "codec-data" field is an AVCDecoderConfigurationRecord, as defined by ISO/IEC 14496-15 (which you can see at [1]). MF_MT_MPEG_SEQUENCE_HEADER, on the other hand, seems to contain the raw SPS/PPS NALUs, start codes and all.
Since Microsoft uses Annex B everywhere, it shouldn't need the codec-data anyway, so I'm curious now why this was added—was there a need for it, or did you just add it on the assumption that the two attributes mapped to each other?
[1] https://doc-kurento.readthedocs.io/en/latest/knowledge/h264.html#gstreamer-…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636#note_45288
Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v25: winesni.drv: add dbus watch instead of using plain unix fds and flush
winesni.drv: replaced the dbus connection logic with a single connection per each SNI object
winesni.drv: wrap functions with pthread mutex locking
winesni.drv: implement basic balloon notification support
explorer: add winesni.drv tray implementation support
winesni.drv: add KDE StatusNotifierItem implementation for tray
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
Fixes Starfield not being able to take photos in photo mode (due to failing to creating windowscodecs' image factory due to COM apartment being initialized). Turns out on Windows RoGetActivationFactory() initializes implicit MTA apartment when called from STA thread, and so after that called once COM is implicitly uninitialized for any (new) thread until COM is uninitialized in the thread which called RoGetActivationFactory (or that thread exited). This is not the case on Win8 (where the function was first introduced) but looks consistent after that.
--
v2: combase: Create implicit MTA in STA apartment in RoGetActivationFactory().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3806
--
v2: gdiplus: Include the newline in the measurement of each line.
gdiplus/tests: Add test for bounds of newline.
win32u: Detect and handle characters that are considered to have no width for GetTextExtentExPoint.
gdi32/tests: Add test for width of carriage return and line feed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3517