October 2022 - wine-gitlab

[PATCH 0/6] MR1158: winegstreamer: Add a skeleton MPEG layer-3 decoder filter.
by Anton Baskanov (＠baskanov) 07 Nov '22

07 Nov '22

Development branch: https://gitlab.winehq.org/baskanov/wine/-/commits/l3codecx/ Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=18773 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1158

4 8

[PATCH v5 0/3] MR574: mf: Improve session pause / restart handling.
by Paul Gofman (＠gofman) 07 Nov '22

07 Nov '22

Patch 1. The tests on Windows show that when the timer callback is queued behind the clock time it is queued and executed quite soon with 0-15ms delay which corresponds to default timer granularity. The timeout tolerance in the test is quite bigger to avoid a flaky test. Wine currently may execute the callback right away or delay it indefinitely depending on the time difference and current system time. Patch 2. It turns out when the session is paused and then restarted and all the samples were delivered to sample grabber before restart, nothing is going to request the samples again when the session is restarted. I am attaching a test in a patch which hopefully confirms how that should work. I am not including that in the patches as the test involves delays (to make sure all the async events settle at certain points) and inherently flaky. Also, _ IMFStreamSink_GetEvent(stream, ...) in the test crashes on Win7 for some unknown reason. [0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch](/uploads/58c1738d48b3392e7ec430a0757210d0/0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch) -- v5: mf/samplegrabber: Handle samples receieved in paused state. mf/samplegrabber: Process samples in paused state in ignore_clock mode. mf: Handle timer time behind clock time in present_clock_schedule_timer(). https://gitlab.winehq.org/wine/wine/-/merge_requests/574

3 6

[PATCH 0/2] MR1106: Enable long types in d3d8.
by eric pouech (＠epo) 05 Nov '22

05 Nov '22

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

4 8

[PATCH 0/1] MR41: vkd3d-shader/hlsl: Print hlsl_fixme() messages using FIXME() as well.
by Zebediah Figura (＠zfigura) 04 Nov '22

04 Nov '22

This makes most vkd3d-shader insufficiencies a lot more obvious when used as an embedded library. The obvious disadvantage here is that vkd3d-compiler will basically print every fixme message twice. This is a bit of an RFC, since I'm not married to this patch. Other potential approaches I see (not all mutually exclusive): * Always print a FIXME if we return VKD3D_ERROR_NOT_IMPLEMENTED from compile_hlsl(), but don't print messages for individual compilation errors. Thus we clue in debuggers that a bug is related to HLSL, but let them use VKD3D_SHADER_DEBUG to find out what the actual bug is. Since the first step is most of the hard part I think this is a reasonable solution. * Or do the same thing from d3dcompiler. * Relegate hlsl_fixme to a separate vkd3d_shader_log_level, and print messages from that log level in d3dcompiler by default. This isn't quite as simple as that though, since currently all the messages are stored in a single blob. * Extra APIs to control whether FIXMES are printed. I'd also like to propose extending whichever of the above solutions to the hlsl_error() / VKD3D_ERROR_INVALID_SHADER cases. That way we catch things which we aren't going to catch via hlsl_fixme(), such as syntax errors from unrecognized keywords. There's a counterargument that compiling an invalid shader is valid usage, and that we (wine or vkd3d) shouldn't print any ERR/FIXME messages when a program does something valid and implemented, but I'd counter that in practice intentionally compiling an invalid shader should be exceedingly rare, and especially for something like wine or vkd3d where debugging is difficult, it's simply not worth insisting on "a correctly functioning program should print no messages" if it's at the cost of making debugging that much harder. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/41

3 6

[PATCH 0/4] MR789: mf: Set source and output nodes media types in the media session.
by Rémi Bernon (＠rbernon) 04 Nov '22

04 Nov '22

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

4 11

[PATCH 0/2] MR1162: ntdll: Use local unwinding reimplementations for Unix libraries on ARM
by Martin Storsjö (＠mstorsjo) 04 Nov '22

04 Nov '22

Currently, unwinding the unix libraries (or full ELF builds) requires having libunwind available. When starting up a wine environment, an exception of type `RPC_S_SERVER_UNAVAILABLE` gets thrown - and if libunwind isn't available, this breaks the startup. Thus, currently on ARM/ARM64, libunwind is essentially mandatory. Additionally, at least on ARM, libunwind seems brittle (commits in latest git master breaks the unwinding use cases in Wine, see e.g. https://github.com/libunwind/libunwind/pull/203#issuecomment-984126066. For ARM, libunwind has currently relied on DWARF debug info in the `.debug_frame` section, since Linux on ARM doesn't use DWARF for runtime unwinding. This MR adds ARM EHABI unwind opcodes where necessary, and adds a local reimplementation of an ARM EHABI/EXIDX/EXTBL unwinder, similar to the DWARF one. With these changes, unwinding on ARM seems to work fine, even without libunwind. See the individual commit messages for more commentary on the decisions taken so far (I've tried to write up all relevant considerations there - it's a fair amount of commentery). A couple open questions: - I wrote the ARM EHABI unwind code mostly with `stdint.h` types like `uint32_t`(as it's in the ntdll/unix directory anyway), but I can rewrite it with `DWORD` or similar if that's preferred. - The ARM EHABI opcodes are enabled for `defined(__arm__) && defined(__ELF__) && defined(__GNUC__) && !defined(__SEH__) && !defined(__ARM_DWARF_EH__)` - there's no define to check for for knowing it's used and enabled, but it has to be implicitly assumed if no other other unwind mechanism is signaled. - The `dl_iterate_phdr` function, used for finding the EXIDX section for locating ARM EHABI unwind info, is used within `#ifdef linux`. It might be available on other OSes too (like FreeBSD etc). Or should I go ahead and add a configure check for it? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1162

4 5

[PATCH v8 0/3] MR231: Draft: SetWindowPos() parent window exposure fixes (#53153)
by Jinoh Kang (＠iamahuman) 03 Nov '22

03 Nov '22

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v8: server: Don't invalidate the newly exposed child region on the parent if it doesn't clip children. https://gitlab.winehq.org/wine/wine/-/merge_requests/231

4 9

[PATCH 0/7] MR43: hlsl: Compute shaders.
by Zebediah Figura (＠zfigura) 02 Nov '22

02 Nov '22

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/43

3 11

[PATCH 0/9] MR1196: winsock: Implement SO_EXCLUSIVEADDR.
by Paul Gofman (＠gofman) 02 Nov '22

02 Nov '22

While adding tests for this I also find a couple of things related to previous MR 1111 which I am also fixing here: - it turns out IPV6 loopback (as in "::1") should not be mapped to ipv4-mapped loopback, ipv6 and ipv4 loopbacks are different addresses. The mapping of that was also missing htonl() for INADDR_LOOPBACK so essentially didn't break anything; - basically the same is for INADDR_ANY (ipv6 "any" doesn't prevent binding to ipv4 "any"), although that is different when SO_EXCLUSIVEADDRUSE is used: in that case ipv6 wildcard address actually blocks ipv4 INADDR_ANY. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1196

4 11

[PATCH 0/1] MR1187: msvcrt: Fix crash due to link err caused by global variable redefine
by wu liande (＠wuliande) 02 Nov '22

02 Nov '22

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

5 10

2025

2024

2023

2022

wine-gitlab October 2022