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
> 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
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
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
I have been instructed by CodeWeavers, on behalf of the CodeWeavers and Wine
leadership, to resign my position as winegstreamer maintainer.
This comes because I have, for technical reasons, rejected or requested changes
to several winegstreamer patches. While these technical objections have not been
responded to, it is believed, in this case, committing patches tested against a
wide range of games, and avoiding a difference against the Proton project,
outweighs all technical problems I may potentially find.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5886
Instead of accessing the surface with macdrv_get_surface_display_image.
--
v7: winemac: Remove unnecessary surface_clip_to_visible_rect.
winemac: Remove now unnecessary cocoa window surface pointer.
winemac: Push window surface image updates to the main thread.
winemac: Create window surface CGImageRef on surface flush.
winemac: Create a provider for the surface and a HBITMAP wrapping it.
winemac: Remove unused macdrv_get_surface_display_image copy_data parameter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5798