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

[PATCH 0/1] MR6690: sort: New program.
by Hans Leidekker (＠hans) Oct. 17, 2024

Oct. 17, 2024

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

4 3

[PATCH v15 0/9] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) Oct. 17, 2024

Oct. 17, 2024

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. -- v15: dlls/winebth.sys: Update radio PDO properties on receiving PropertiesChanged for an org.bluez.Adapter1 object. dlls/winebth.sys: Remove the corresponding radio PDO on receiving InterfacesRemoved for a org.bluez.Adapter1 object. dlls/winebth.sys: Create new radio PDOs on receiving InterfacesAdded for objects that implement org.bluez.Adapter1. dlls/winebth.sys: Set radio PDO properties from the device's corresponding org.bluez.Adapter1 object properties. 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. dlls/winebth.sys: Add a basic unixlib stub using DBus. dlls/winebth.sys: Add base winebth.sys driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 11

[PATCH 0/3] MR6689: include: Add IUISettings4/5/6 definition in windows.ui.viewmanagement.idl.
by Biswapriyo Nath (＠Biswa96) Oct. 17, 2024

Oct. 17, 2024

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

2 3

[PATCH v14 0/9] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) Oct. 17, 2024

Oct. 17, 2024

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. -- v14: dlls/winebth.sys: Update radio PDO properties on receiving PropertiesChanged for an org.bluez.Adapter1 object. dlls/winebth.sys: Remove the corresponding radio PDO on receiving InterfacesRemoved for a org.bluez.Adapter1 object. dlls/winebth.sys: Create new radio PDOs on receiving InterfacesAdded for objects that implement org.bluez.Adapter1. dlls/winebth.sys: Set radio PDO properties from the device's corresponding org.bluez.Adapter1 object properties. 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. dlls/winebth.sys: Add a basic unixlib stub using DBus. dlls/winebth.sys: Add base winebth.sys driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

4 36

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

Oct. 17, 2024

These patches finish moving targa file handling into d3dx9. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6688

2 6

[PATCH v3 0/4] MR6658: ddraw: Some fixes for SwapTextureHandles().
by Paul Gofman (＠gofman) Oct. 17, 2024

Oct. 17, 2024

First of all it fixes a regression introduced by 5a7ff3b45c78784dca0a465d9e21483f72bce6e5 when surface handles were moved to global table but SwapTextureHandles was left behind (https://bugs.winehq.org/show_bug.cgi?id=57300) Then, I am fixing a couple of more issues with this function spotted on the way. I did some initial testing of SwapTextures across devices and that looks messy, device on which the swap is performed influences the outcome in some not immediately obvious way. I omitted the investigation of that because multiple 3d devices in ddraw is already a very exotic use case and I think we are unlikely to meet the usage of SwapTextures across multiple devices. -- v3: ddraw: Update state if d3d_device2_SwapTextureHandles() results in texture change. ddraw: Validate handles in d3d_device2_SwapTextureHandles(). ddraw: Use global handle table in d3d_device2_SwapTextureHandles(). https://gitlab.winehq.org/wine/wine/-/merge_requests/6658

4 7

[PATCH 0/1] MR6666: ntdll: Implement NtWow64QueryInformationProcess64.
by Alex Henrie (＠alexhenrie) Oct. 17, 2024

Oct. 17, 2024

Needed for GOG Galaxy. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6666

5 5

Re: [PATCH v2 0/1] MR6687: apisetschema: Add api-ms-win-rtcore-ntuser-private-l1-1-1. - closed
by Zhiyi Zhang (＠zhiyi) Oct. 17, 2024

Oct. 17, 2024

This merge request was closed by Zhiyi Zhang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6687

1 0

Re: [PATCH v2 0/1] MR6687: apisetschema: Add api-ms-win-rtcore-ntuser-private-l1-1-1.
by Zhiyi Zhang (＠zhiyi) Oct. 17, 2024

Oct. 17, 2024

On Thu Oct 17 09:32:21 2024 +0000, Alexandre Julliard wrote: > The final version number is supposed to be ignored. Where does this make > a difference? Oh, I see. This is not needed then. Closing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6687#note_85284

1 0

Re: [PATCH v2 0/1] MR6687: apisetschema: Add api-ms-win-rtcore-ntuser-private-l1-1-1.
by Alexandre Julliard (＠julliard) Oct. 17, 2024

Oct. 17, 2024

The final version number is supposed to be ignored. Where does this make a difference? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6687#note_85282

1 0