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

Re: [PATCH v15 0/3] MR8200: cmd: COPY should output file names as they are copied.
by Joe Souza (＠JoeS209) June 12, 2025

June 12, 2025

On Thu Jun 12 17:34:38 2025 +0000, eric pouech wrote: > you should support the same parameters as below > likely you'd better have the {cc=len; } body when > parameter_with_delims() fails I'm not sure that I understand the question. There are the delimiters that WCMD_parameter uses to parse the entire command line into different paths. Then for tab-completion, I need to parse for the search and insert points within each path. These delimiters are not the same. For example, given the following string: DIR C:\tmp C:\windows\sys<tab> WCMD_parameters needs to parse that into the separate paths. Then, once I have C:\windows\sys<tab>, I have to search for C:\windows\sys*, and then insert the results at the last \, i.e. replace sys<tab> with system, etc. There is no need to parse the path for characters like \t, etc., because that cannot exist in a legal path and would have already been parsed out previously by the call to WCMD_parameter. Further, the code at line 141 exists at all because in the case of COPY file1+<tab>, WCMD_parameter finds file1 as the last parameter, but for tab-completion I need to perform a wildcard search starting after the +. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_106387

1 0

Re: [PATCH v15 0/3] MR8200: cmd: COPY should output file names as they are copied.
by Joe Souza (＠JoeS209) June 12, 2025

June 12, 2025

On Thu Jun 12 17:34:46 2025 +0000, eric pouech wrote: > ditto is there a reason to not handle the other delimiters here? Mainly same reason as other answer, that the delimiters that I need to parse within a given path are not the same as the delimiters needed by WCMD_parameter to pass a multi-path string into separate paths. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_106386

1 0

[PATCH v8 0/5] MR8174: winebth.sys part 12: Introduce support for Low Energy GATT services
by Vibhav Pant (＠vibhavp) June 12, 2025

June 12, 2025

Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively. This MR introduces initial support for accessing GATT services on LE devices: * Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them. * Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately. * Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices. * Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs. * Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices). -- v8: bluetoothapis/tests: Add tests for BluetoothGATTGetServices. bluetoothapis: Implement BluetoothGATTGetServices. https://gitlab.winehq.org/wine/wine/-/merge_requests/8174

2 6

[PATCH v6 0/5] MR8174: winebth.sys part 12: Introduce support for Low Energy GATT services
by Vibhav Pant (＠vibhavp) June 12, 2025

June 12, 2025

Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively. This MR introduces initial support for accessing GATT services on LE devices: * Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them. * Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately. * Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices. * Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs. * Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices). -- v6: bluetoothapis/tests: Add tests for BluetoothGATTGetServices. bluetoothapis: Implement BluetoothGATTGetServices. winebth.sys: Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES. winebth.sys: Store a list of GATT services discovered on LE devices. winebth.sys: Create PDOs for remote Bluetooth devices. https://gitlab.winehq.org/wine/wine/-/merge_requests/8174

2 9

[PATCH 0/1] MR8296: msi/tests: Fix wrong character count for RegSetValueExA.
by Yuxuan Shui (＠yshui) June 12, 2025

June 12, 2025

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

2 1

[PATCH 0/1] MR8275: wined3d/vk: Use the XY11 fixup for SNORM formats only for legacy d3d.
by Elizabeth Figura (＠zfigura) June 12, 2025

June 12, 2025

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

4 5

[PATCH v3 0/1] MR8274: wined3d/spirv: Limit parameters to the relevant shader versions.
by Elizabeth Figura (＠zfigura) June 12, 2025

June 12, 2025

-- v3: wined3d/spirv: Limit parameters to the relevant shader versions. https://gitlab.winehq.org/wine/wine/-/merge_requests/8274

3 2

[PATCH 0/1] MR8284: d3dx9/tests: Add a few tests for technique/pass access with the effect compiler API.
by Nikolay Sivov (＠nsivov) June 12, 2025

June 12, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8284

3 2

[PATCH v2 0/2] MR8245: d3dcompiler_43: Implement D3DCreateLinker().
by Zhiyi Zhang (＠zhiyi) June 12, 2025

June 12, 2025

For React Native. React Native applications use HLSL shader linking extensively. Obviously, these two functions are not enough because they are just stubs. But I think it's good to get them in the tree so they don't get lost. Currently, React Native applications need to rely on the bundled native d3dcompiler. -- v2: d3dcompiler_47: Implement D3DCreateFunctionLinkingGraph(). d3dcompiler_47: Implement D3DCreateLinker(). https://gitlab.winehq.org/wine/wine/-/merge_requests/8245

3 4

[PATCH 0/2] MR8226: d3dx9: Replace libtxc_dxtn.
by Connor McAdams (＠cmcadams) June 12, 2025

June 12, 2025

These patches replace the existing libtxc_dxtn texture compression/decompression source files with new libraries that can handle more formats. This is will be helpful when we begin to share code with d3dx10/d3dx11, as we will be able to use bcdec to decode all supported compressed formats, and stb_dxt to compress BC1-BC5. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8226

3 8