Right now this should not do anything because all windows are per-monitor DPI aware. When this is changed this will automatically fall back to window surface scaling through `NtGdiStretchBlt` in win32u.
This has the disadvantage that `NtGdiStretchBlt` is doing an absolutely terrible job at upscaling. This then adds a way for drivers to opt-in and do their own surface scaling before falling back to win32u. Alternatively and perhaps better, we could pull libcairo and use it to scale the surface contents with high quality filtering instead of using GDI.
--
v3: win32u: Implement DPI scaled window surface.
win32u: Move window_surface creation helper to dce.c.
win32u: Map window rects DPI before calling into the drivers.
win32u: Map window region DPI before calling into the drivers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6331
--
v7: winex11: Map message pos to physical DPI in move_resize_window.
win32u: Avoid changing thread DPI context in process_hardware_message.
win32u: Factor hardware message point DPI mapping together.
win32u: Use map_window_points with explicit DPI over screen_to_client.
win32u: Split hardware message window lookup to a separate helper.
win32u: Use per-monitor DPI window_from_point in process_mouse_message.
win32u: Parameterize window_from_point dpi.
server: Pass window's per-monitor DPI in set_window_pos.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5819
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.
--
v2: winex11.drv: Fix a possible desktop window message queue hang.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5890