June 2024 - Wine-GitLab - list.winehq.org

[PATCH v3 0/2] MR5761: comclt32: Allow ctrl-tab and tab hotkeys for propsheets
by Fabian Maurer (＠DarkShadow44) June 20, 2024

June 20, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56103 -- v3: comclt32: Allow hotkeys for propsheet navigation https://gitlab.winehq.org/wine/wine/-/merge_requests/5761

3 10

[PATCH 0/1] MR5890: winex11.drv: Fix a possible desktop window message queue hang.
by Zhiyi Zhang (＠zhiyi) June 20, 2024

June 20, 2024

After an X11 event handler queues messages to another thread, TRUE should be returned and eventually propagated to X11DRV_ProcessEvents(). When FALSE is always returned in xrandr14_device_change_handler(), a possible hang can happen for the desktop message queue as follows: 1. The explorer.exe calls GetMessageW() -> NtUserGetMessage() -> wait_objects() -> wait_message(). 2. In wait_message(), user_driver->pProcessEvents() gets called in the desktop window thread to handle RRNotify events and calls xrandr14_device_change_handler() -> display_mode_changed(FALSE) -> send_message(get_desktop_window(), WM_DISPLAYCHANGE, ...) -> desktop_window_proc() -> send_message_timeout() -> send_client_message() -> process_message() -> broadcast_message() -> send_message_timeout() -> send_client_message() -> process_message() -> send_inter_thread_message() -> wait_message_reply() -> a server set_queue_mask() with skip_wait being 1 -> wake_mask and changed_mask are set to 0. 3. In wait_message(), user_driver->pProcessEvents() returns FALSE from xrandr14_device_change_handler(). So wait_message() continues to call NtWaitForMultipleObjects(). 4. Now NtWaitForMultipleObjects() hangs for INFINITE timeout because wake_mask and changed_mask for the message queue are set to 0 so the thread is not woke up. The hang is sensitive to message ordering and only happens in this specific case so it's hard to reproduce with tests. I believe some of the past test timeouts on TestBots can be attributed to this bug. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5890

2 2

[PATCH v3 0/2] MR5879: winegstreamer: Implement stubs for h264 encoder.
by Ziqing Hui (＠zhui) June 20, 2024

June 20, 2024

-- v3: winegstreamer: Implement stubs for h264 encoder. mf/tests: Add tests for H264 encoder types. https://gitlab.winehq.org/wine/wine/-/merge_requests/5879

4 5

[PATCH 0/4] MR5889: Cmd engine rewrite (part VII)
by eric pouech (＠epo) June 20, 2024

June 20, 2024

This is part VII of cmd engine rewrite. It finishes spliting parsing from execution of FOR loops. And fixes reading from NUL for confirmation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5889

2 4

[PATCH 0/4] MR5875: mmdevapi: Complete IAudioClient3 implementation.
by Davide Beatrici (＠davidebeatrici) June 20, 2024

June 20, 2024

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

3 11

[PATCH 0/1] MR5888: ntdll: Fix handling of non-string types with RTL_QUERY_REGISTRY_DIRECT.
by Alex Henrie (＠alexhenrie) June 20, 2024

June 20, 2024

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

2 1

Re: [PATCH v2 0/5] MR5879: winegstreamer: Implement stubs for h264 encoder.
by Ziqing Hui (＠zhui) June 19, 2024

June 19, 2024

> I don't want to be a blocker but to be honest I'm a bit annoyed with the idea of having to rewrite the patches I am trying to upstream with transform media types. I'm going to delay making changes to wg_transform until you upstream your transform patches. I can concentrate on implementing the frontside first. So I'll simply remove patch 3,4,5 in this MR for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5879#note_73808

1 0

Re: [PATCH v2 0/5] MR5879: winegstreamer: Implement stubs for h264 encoder.
by Ziqing Hui (＠zhui) June 19, 2024

June 19, 2024

On Wed Jun 19 15:58:14 2024 +0000, Elizabeth Figura wrote: > > Can we add an encoder element without changing all this code? It > doesn't look like you need all the complicated converter sequence, maybe > only a videoconvert (do you even need one?). > Yeah, in general the idea that we'd want the same sequence for decoding > and encoding is probably wrong. E.g. for decoding we may want > deinterlace, but we certainly don't want that for encoding. It's > probably better to handle them separately. Yeah, we can make things easy for encoder for now, only creating encoder element. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5879#note_73807

1 0

[PATCH 0/4] MR5887: mshtml: Add support for using apply and call on (legacy) builtin function objects.
by Jacek Caban (＠jacek) June 19, 2024

June 19, 2024

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

3 5

[PATCH v2 0/1] MR5871: ntdll: Fix macOS build errors with Xcode 16.
by Brendan Shanks (＠bshanks) June 19, 2024

June 19, 2024

LLVM 17 or 18 no longer allow non-private labels to appear between .cfi_startproc/endproc when targeting Mach-O. Similar fixes as in commit 295d521b11644fb76c36854336b13c2155bb7d79. Since this is needed for 2 out of 4 architectures, would it be better to do it for all 4 and then modify the shared `__wine_syscall_dispatcher_return()` prototype? -- v2: ntdll: Make __wine_syscall_dispatcher_return a separate function to fix Xcode 16 build errors. https://gitlab.winehq.org/wine/wine/-/merge_requests/5871

3 3