- wine-gitlab - winehq.org

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Anton Baskanov (＠baskanov) 18 Oct '24

18 Oct '24

On Fri Oct 18 14:05:23 2024 +0000, Rémi Bernon wrote: > I see, I think this should not be necessary anymore since !6573, the new > display mode will be written to the registry and other processes/threads > should get their cache invalidate immediately. > Later on, when the XRandR events are processed the cache might get > invalidated again but should end up with the same display settings. The issue was specifically with seeing mode changes from other processes. The test calls `EnumDisplaySettings()` in a loop waiting for the expected mode change. If we don't process `RRNotify` events in `xrandr14_get_id()` we won't see the new mode until some thread processes the messages. Since there are no such threads in the test process, the test will fail. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85467

1 0

[PATCH v8 0/8] MR6649: winex11: Replace foreign windows with a driver-only host window tracking.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

Making all the windows handled by the driver to be either GL/VK client surfaces, or top-level windows. This avoids leaking host windows into the Win32 space, and makes it possible to get rid of some remaining NtUserMapWindowPoints in `map_event_coords` for mouse input. -- v8: winex11: Get rid of the now unnecessary foreign windows. winex11: Generate relative ConfigureNotify on parent ConfigureNotify events. winex11: Use the new host windows to register foreign window events. winex11: Keep track of the host windows children window rects. winex11: Keep track of the host windows relative rects. winex11: Keep track of the host window children of interest. winex11: Create host windows recursively up to root_window. winex11: Introduce a new struct host_window for host-only windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/6649

3 12

[PATCH v3 0/4] MR6602: explorer, services: Use admin tokens when appropriate.
by Tim Clem (＠tclem) 18 Oct '24

18 Oct '24

Let me know if you'd like me to split this up. As per feedback, I'm now doing the admin token-setting via an extension to NtSetInformationProcess. Testing on Windows shows that the owner of GetDesktopWindow() always has a default admin token with `TokenElevationTypeDefault`, no matter the token of the process/thread that is responsible for creating it. We've had issues in this area in the past - 99e2fad1 was a case where it was important that explorer not inherit the token of the *process* spawning it, but instead the token of the *thread*. This patch keeps that app working, since now explorer will set a default token regardless. In addition to the privilege issues from 99e2fad1, it is a relatively common pattern to duplicate the token of the owner of GetDesktopWindow to acquire a default token. Services are also currently launched with limited tokens, so this series also has services.exe elevate itself. -- v3: services: Apply a default admin token to the process. ntdll: Count default-elevation admin tokens as elevated from NtQueryInformationToken(TokenElevation). https://gitlab.winehq.org/wine/wine/-/merge_requests/6602

4 6

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

On Fri Oct 18 13:56:14 2024 +0000, Zhiyi Zhang wrote: > If I remember correctly, it's for other threads other than the > explorer's main thread to see the new display mode immediately. Without > it, a rather large delay is causing tests to fail. I see, I think this should not be necessary anymore since !6573, the new display mode will be written to the registry and other processes/threads should get their cache invalidate immediately. Later on, when the XRandR events are processed the cache might get invalidated again but should end up with the same display settings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85457

1 0

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Zhiyi Zhang (＠zhiyi) 18 Oct '24

18 Oct '24

On Fri Oct 18 13:56:14 2024 +0000, Rémi Bernon wrote: > Do you recall why b3eb55227aef198a637f80a2fa0bce74aa0a7190 is actually > required? Can't we just wait until the RRNotify events are received and > processed from whichever thread listens to them? > Fwiw it is causing some rare deadlocks with this kind of pattern: > 1) thread A holds `display_lock` and wants `user_lock`: > ``` > #4 0x00007f3f11236940 in user_lock () at ./dlls/win32u/sysparams.c:295 > #5 0x00007f3f11246551 in get_user_handle_ptr (type=1, handle=0x10020) > at ./dlls/win32u/window.c:90 > #6 get_win_ptr (hwnd=0x10020) at ./dlls/win32u/window.c:249 > #7 0x00007f3f11246e2b in get_window_thread (hwnd=0x10020, process=0x0) > at ./dlls/win32u/window.c:320 > #8 0x00007f3f1124ce8d in NtUserCallHwndParam (hwnd=hwnd@entry=0x10020, > param=param@entry=0, code=code@entry=16) at ./dlls/win32u/window.c:5892 > #9 0x00007f3f10c6803f in NtUserGetWindowThread (process=0x0, > hwnd=0x10020) at ./include/ntuser.h:1431 > #10 xrandr14_device_change_handler (hwnd=0x10020, event=<optimized out>) > at ./dlls/winex11.drv/xrandr.c:1221 > #11 0x00007f3f10c3535f in call_event_handler > (display=display@entry=0x55558c2bdcd0, event=event@entry=0x7ffffe0f9a80) > at ./dlls/winex11.drv/event.c:460 > #12 0x00007f3f10c37e27 in process_events (display=<optimized out>, > filter=filter@entry=0x7f3f10c65c30 <filter_rrnotify_event>, > arg=<optimized out>) at ./dlls/winex11.drv/event.c:518 > #13 0x00007f3f10c68f4f in process_rrnotify_events () at ./dlls/winex11.drv/xrandr.c:1270 > #14 xrandr14_get_id (device_name=<optimized out>, is_primary=<optimized > out>, id=0x7ffffe0f9c98) at ./dlls/winex11.drv/xrandr.c:1288 > #15 0x00007f3f10c33fe7 in X11DRV_UpdateDisplayDevices > (device_manager=0x7f3f1129f700 <device_manager>, param=0x7ffffe0fa680) > at ./dlls/winex11.drv/display.c:453 > #16 0x00007f3f11236ba8 in update_display_devices (ctx=0x7ffffe0fa680) at ./dlls/win32u/sysparams.c:2027 > #17 update_display_cache (force=force@entry=1) at ./dlls/win32u/sysparams.c:2072 > #18 0x00007f3f11238e5f in display_mode_changed (broadcast=1) at ./dlls/win32u/sysparams.c:3473 > #19 0x00007f3f11239cd2 in apply_display_settings > (target=target@entry=0x0, devmode=devmode@entry=0x0, > hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/win32u/sysparams.c:3566 > #20 0x00007f3f1123d57d in NtUserChangeDisplaySettings > (devname=0x7ffffe2fe600, devmode=0x0, hwnd=0x0, flags=0, lparam=0x0) at ./dlls/win32u/sysparams.c:3583 > #21 <signal handler called> > #22 0x00006ffffe08bd74 in NtUserChangeDisplaySettings () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll > #23 0x00006ffffe0dfdc3 in ChangeDisplaySettingsExW > (devname=devname@entry=0x0, devmode=devmode@entry=0x0, > hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/user32/sysparams.c:549 > #24 0x00006ffffa591779 in wined3d_restore_display_modes > (wined3d=0x7ffffe2fec48) at ./dlls/wined3d/directx.c:1636 > #25 0x00006ffffa59d54e in wined3d_swapchain_activate > (swapchain=0x7fffff26eaa0, activate=0, activate@entry=32767) at ./dlls/wined3d/swapchain.c:1899 > ``` > 2) thread B holds `user_lock` and wants `display_lock`: > ``` > #4 0x00007f3f1123adcc in lock_display_devices () at ./dlls/win32u/sysparams.c:2100 > #5 get_virtual_screen_rect (dpi=dpi@entry=0, type=<optimized out>) at ./dlls/win32u/sysparams.c:2520 > #6 0x00007f3f112439a7 in NtUserCallTwoParam > (arg1=arg1@entry=140737480547808, arg2=arg2@entry=0, code=code@entry=10) > at ./dlls/win32u/sysparams.c:6758 > #7 0x00007f3f10c5a208 in NtUserGetVirtualScreenRect > (type=MDT_EFFECTIVE_DPI) at ./include/ntuser.h:1155 > #8 X11DRV_ReleaseDC (hwnd=<optimized out>, hdc=0x22010048) at ./dlls/winex11.drv/window.c:2700 > #9 0x00007f3f111842bd in release_dce (dce=dce@entry=0x55558c2a97b0) at ./dlls/win32u/dce.c:887 > #10 0x00007f3f11184810 in release_dce (dce=0x55558c2a97b0) at ./dlls/win32u/dce.c:1138 > #11 0x00007f3f11187118 in invalidate_dce (win=win@entry=0x7f3ec00aa020, > old_rect=old_rect@entry=0x7fffff88dfd0) at ./dlls/win32u/dce.c:1201 > #12 0x00007f3f1124e25c in apply_window_pos (hwnd=hwnd@entry=0x6004e, > insert_after=insert_after@entry=0x0, swp_flags=6207, > swp_flags@entry=6175, new_surface=new_surface@entry=0x7f3ec009f210, > new_rects=new_rects@entry=0x7fffff88e170, > valid_rects=valid_rects@entry=0x7fffff88e150) at ./dlls/win32u/window.c:2084 > #13 0x00007f3f112519fa in update_window_state (hwnd=0x6004e) at ./dlls/win32u/window.c:4523 > #14 0x00007f3f1120dedd in handle_internal_message (hwnd=<optimized out>, > msg=<optimized out>, wparam=0, lparam=<optimized out>) at ./dlls/win32u/message.c:2125 > #15 0x00007f3f112122a1 in peek_message (msg=msg@entry=0x7fffff88e9f0, > filter=filter@entry=0x7fffff88e9d0) at ./dlls/win32u/message.c:2923 > #16 0x00007f3f112138c8 in NtUserPeekMessage (msg_out=0x7fffffa8ff00, > hwnd=<optimized out>, first=<optimized out>, last=<optimized out>, > flags=<optimized out>) at ./dlls/win32u/message.c:3242 > #17 <signal handler called> > #18 0x00006ffffe08cd54 in NtUserPeekMessage () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll > #19 0x00006ffffe113965 in PeekMessageW (flags=1024, last=<optimized > out>, first=<optimized out>, hwnd=<optimized out>, > msg_out=0x7fffffa8ff00) at ./dlls/user32/message.c:762 > #20 PeekMessageA (msg=0x7fffffa8ff00, hwnd=<optimized out>, > first=<optimized out>, last=<optimized out>, flags=1) at ./dlls/user32/message.c:772 > ``` > This happens randomly, perhaps more frequently since > 2b32c2859166e5542012b517cdef4699d8bb322c, but `update_window_state` > could already be called before in other circumstances, and it should not > cause a deadlock. > More specifically, I don't think we should try to acquire `user_lock` > with `display_lock` held, only the other way around. If I remember correctly, it's for other threads other than the explorer's main thread to see the new display mode immediately. Without it, a rather large delay is causing tests to fail. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85456

1 0

[PATCH 0/2] MR6685: win32u: Fixes for arc drawing.
by Elizabeth Figura (＠zfigura) 18 Oct '24

18 Oct '24

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

4 4

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

Do you recall why b3eb55227aef198a637f80a2fa0bce74aa0a7190 is actually required? Can't we just wait until the RRNotify events are received and processed from whichever thread listens to them? Fwiw it is causing some rare deadlocks with this kind of pattern: 1) thread A holds `display_lock` and wants `user_lock`: ``` #4 0x00007f3f11236940 in user_lock () at ./dlls/win32u/sysparams.c:295 #5 0x00007f3f11246551 in get_user_handle_ptr (type=1, handle=0x10020) at ./dlls/win32u/window.c:90 #6 get_win_ptr (hwnd=0x10020) at ./dlls/win32u/window.c:249 #7 0x00007f3f11246e2b in get_window_thread (hwnd=0x10020, process=0x0) at ./dlls/win32u/window.c:320 #8 0x00007f3f1124ce8d in NtUserCallHwndParam (hwnd=hwnd@entry=0x10020, param=param@entry=0, code=code@entry=16) at ./dlls/win32u/window.c:5892 #9 0x00007f3f10c6803f in NtUserGetWindowThread (process=0x0, hwnd=0x10020) at ./include/ntuser.h:1431 #10 xrandr14_device_change_handler (hwnd=0x10020, event=<optimized out>) at ./dlls/winex11.drv/xrandr.c:1221 #11 0x00007f3f10c3535f in call_event_handler (display=display@entry=0x55558c2bdcd0, event=event@entry=0x7ffffe0f9a80) at ./dlls/winex11.drv/event.c:460 #12 0x00007f3f10c37e27 in process_events (display=<optimized out>, filter=filter@entry=0x7f3f10c65c30 <filter_rrnotify_event>, arg=<optimized out>) at ./dlls/winex11.drv/event.c:518 #13 0x00007f3f10c68f4f in process_rrnotify_events () at ./dlls/winex11.drv/xrandr.c:1270 #14 xrandr14_get_id (device_name=<optimized out>, is_primary=<optimized out>, id=0x7ffffe0f9c98) at ./dlls/winex11.drv/xrandr.c:1288 #15 0x00007f3f10c33fe7 in X11DRV_UpdateDisplayDevices (device_manager=0x7f3f1129f700 <device_manager>, param=0x7ffffe0fa680) at ./dlls/winex11.drv/display.c:453 #16 0x00007f3f11236ba8 in update_display_devices (ctx=0x7ffffe0fa680) at ./dlls/win32u/sysparams.c:2027 #17 update_display_cache (force=force@entry=1) at ./dlls/win32u/sysparams.c:2072 #18 0x00007f3f11238e5f in display_mode_changed (broadcast=1) at ./dlls/win32u/sysparams.c:3473 #19 0x00007f3f11239cd2 in apply_display_settings (target=target@entry=0x0, devmode=devmode@entry=0x0, hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/win32u/sysparams.c:3566 #20 0x00007f3f1123d57d in NtUserChangeDisplaySettings (devname=0x7ffffe2fe600, devmode=0x0, hwnd=0x0, flags=0, lparam=0x0) at ./dlls/win32u/sysparams.c:3583 #21 <signal handler called> #22 0x00006ffffe08bd74 in NtUserChangeDisplaySettings () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll #23 0x00006ffffe0dfdc3 in ChangeDisplaySettingsExW (devname=devname@entry=0x0, devmode=devmode@entry=0x0, hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/user32/sysparams.c:549 #24 0x00006ffffa591779 in wined3d_restore_display_modes (wined3d=0x7ffffe2fec48) at ./dlls/wined3d/directx.c:1636 #25 0x00006ffffa59d54e in wined3d_swapchain_activate (swapchain=0x7fffff26eaa0, activate=0, activate@entry=32767) at ./dlls/wined3d/swapchain.c:1899 ``` 2) thread B holds `user_lock` and wants `display_lock`: ``` #4 0x00007f3f1123adcc in lock_display_devices () at ./dlls/win32u/sysparams.c:2100 #5 get_virtual_screen_rect (dpi=dpi@entry=0, type=<optimized out>) at ./dlls/win32u/sysparams.c:2520 #6 0x00007f3f112439a7 in NtUserCallTwoParam (arg1=arg1@entry=140737480547808, arg2=arg2@entry=0, code=code@entry=10) at ./dlls/win32u/sysparams.c:6758 #7 0x00007f3f10c5a208 in NtUserGetVirtualScreenRect (type=MDT_EFFECTIVE_DPI) at ./include/ntuser.h:1155 #8 X11DRV_ReleaseDC (hwnd=<optimized out>, hdc=0x22010048) at ./dlls/winex11.drv/window.c:2700 #9 0x00007f3f111842bd in release_dce (dce=dce@entry=0x55558c2a97b0) at ./dlls/win32u/dce.c:887 #10 0x00007f3f11184810 in release_dce (dce=0x55558c2a97b0) at ./dlls/win32u/dce.c:1138 #11 0x00007f3f11187118 in invalidate_dce (win=win@entry=0x7f3ec00aa020, old_rect=old_rect@entry=0x7fffff88dfd0) at ./dlls/win32u/dce.c:1201 #12 0x00007f3f1124e25c in apply_window_pos (hwnd=hwnd@entry=0x6004e, insert_after=insert_after@entry=0x0, swp_flags=6207, swp_flags@entry=6175, new_surface=new_surface@entry=0x7f3ec009f210, new_rects=new_rects@entry=0x7fffff88e170, valid_rects=valid_rects@entry=0x7fffff88e150) at ./dlls/win32u/window.c:2084 #13 0x00007f3f112519fa in update_window_state (hwnd=0x6004e) at ./dlls/win32u/window.c:4523 #14 0x00007f3f1120dedd in handle_internal_message (hwnd=<optimized out>, msg=<optimized out>, wparam=0, lparam=<optimized out>) at ./dlls/win32u/message.c:2125 #15 0x00007f3f112122a1 in peek_message (msg=msg@entry=0x7fffff88e9f0, filter=filter@entry=0x7fffff88e9d0) at ./dlls/win32u/message.c:2923 #16 0x00007f3f112138c8 in NtUserPeekMessage (msg_out=0x7fffffa8ff00, hwnd=<optimized out>, first=<optimized out>, last=<optimized out>, flags=<optimized out>) at ./dlls/win32u/message.c:3242 #17 <signal handler called> #18 0x00006ffffe08cd54 in NtUserPeekMessage () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll #19 0x00006ffffe113965 in PeekMessageW (flags=1024, last=<optimized out>, first=<optimized out>, hwnd=<optimized out>, msg_out=0x7fffffa8ff00) at ./dlls/user32/message.c:762 #20 PeekMessageA (msg=0x7fffffa8ff00, hwnd=<optimized out>, first=<optimized out>, last=<optimized out>, flags=1) at ./dlls/user32/message.c:772 ``` This happens randomly, perhaps more frequently since 2b32c2859166e5542012b517cdef4699d8bb322c, but `update_window_state` could already be called before in other circumstances, and it should not cause a deadlock. More specifically, I don't think we should try to acquire `user_lock` with `display_lock` held, only the other way around. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85453

1 0

[PATCH v2 0/6] MR6688: d3dx9: Move targa decoding into d3dx9, part 2.
by Connor McAdams (＠cmcadams) 18 Oct '24

18 Oct '24

These patches finish moving targa file handling into d3dx9. -- v2: d3dx9: Add support for decoding targa files with a color map in d3dx9. d3dx9: Add support for decoding targa files with run length encoding in d3dx9. d3dx9: Add support for decoding targa files with different pixel orders in d3dx9. d3dx9: Add support for loading basic targa images without WIC. d3dx9/tests: Add more tests for loading targa files. https://gitlab.winehq.org/wine/wine/-/merge_requests/6688

4 14

[PATCH 0/1] MR6693: mlang: Only consider true type fonts in map_font().
by Danyil Blyschak (＠blyss) 18 Oct '24

18 Oct '24

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

3 2

[PATCH v2 0/4] MR6695: ntdll/tests: Add reserve object tests.
by Zhiyi Zhang (＠zhiyi) 18 Oct '24

18 Oct '24

Add tests for object type IoCompletionReserve and UserApcReserve. -- v2: ntdll/tests: Add NtAllocateReserveObject() tests. ntdll: Implement NtAllocateReserveObject(). ntdll/tests: Add reserve object tests. gitlab: Update generated files for static analysis. https://gitlab.winehq.org/wine/wine/-/merge_requests/6695

3 6

[PATCH 0/3] MR6695: ntdll/tests: Add reserve object tests.
by Zhiyi Zhang (＠zhiyi) 18 Oct '24

18 Oct '24

Add tests for object type IoCompletionReserve and UserApcReserve. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6695

2 3

[PATCH 0/6] MR6694: user32: Move DND code from winex11 XDND.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

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

2 6

[PATCH v22 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v22: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 6

[PATCH v21 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v21: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 6

Re: [PATCH v2 0/1] MR6692: ntdll: Add a stub implementation of NtQueryInformationThread(ThreadIdealProcessorEx). - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6692

1 0

Re: [PATCH v2 0/1] MR6691: findstr: Fix codepage passed to WideCharToMultiByte(). - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6691

1 0

Re: [PATCH v2 0/3] MR6689: include: Add IUISettings4/5/6 definition in windows.ui.viewmanagement.idl. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6689

1 0

Re: [PATCH v4 0/4] MR6658: ddraw: Some fixes for SwapTextureHandles(). - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6658

1 0

Re: [PATCH v4 0/1] MR6661: winegstreamer: Use wmaversion = 4 for MFAudioFormat_WMAudio_Lossless. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6661

1 0

Re: [PATCH v2 0/5] MR6686: winex11: More XDND code cleanup. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6686

1 0

Re: [PATCH v3 0/1] MR6674: xml2: Import upstream release 2.12.8. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6674

1 0

[PATCH v20 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v20: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 5

[PATCH v19 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v19: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 6

[PATCH 0/1] MR6691: findstr: Fix codepage passed to WideCharToMultiByte().
by Hans Leidekker (＠hans) 17 Oct '24

17 Oct '24

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

3 2

[PATCH v18 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v18: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 8

2025

2024

2023

2022

wine-gitlab