August 2024 - Wine-gitlab - list.winehq.org

[PATCH 0/1] MR6422: include: Add ISelectionProvider2 definition in uiautomationcore.idl
by Biswapriyo Nath (＠Biswa96) 31 Aug '24

31 Aug '24

Required for https://github.com/juce-framework/JUCE/blob/8.0.1/modules/juce_gui_basics/n… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6422

3 2

[PATCH v12 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 31 Aug '24

31 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v12: bluetoothapis/tests: Add tests for BluetoothSdpEnumAttributes and BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpGetContainerElementData and BluetoothSdpGetElementData. bluetoothapis: Implement BluetoothSdpEnumAttributes. bluetoothapis: Implement BluetoothSdpGetContainerElementData. bluetoothapis: Implement BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

[PATCH 0/6] MR6360: d3dx9: Beginning of pixel format handling changes.
by Connor McAdams (＠cmcadams) 30 Aug '24

30 Aug '24

This is the initial set of patches for handling new pixel format types. I've pushed a branch [here](https://gitlab.winehq.org/cmcadams/wine/-/commits/WIP/d3dx-shared-sou… containing the rest of my current patches if additional context would be useful, the new format handling patches end with `ed7022a0838b346f4fa2b229ce7e8e6b8ebc2244`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6360

3 24

Re: [PATCH v2 0/3] MR6407: include: Updated a few gdiplus types. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6412: winecoreaudio: Set the synth volume to the greater of the left and right channels. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6415: mscoree: Update Wine Mono to 9.3.0. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6416: secur32: Ensure unixlib function tables and enum stay in sync. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6414: secur32: Simplify the cred_enabled_protocols logic slightly. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/5] MR6411: Cmd engine rewrite (part XXIII) - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Rémi Bernon 30 Aug '24

30 Aug '24

On Fri Aug 30 18:00:21 2024 +0000, Vibhav Pant wrote: > > Maybe we can avoid sending the paths every time by moving the > filtering to plugplay, adapting the interface a bit for this. There > could be additional methods to register paths / get plugplay handles in > return, and later use these handle as device handles. > Perhaps, but wouldn't this make both plugplay service, and the > notification code sechost/service.c a lot more stateful as a result? Re: > device handles, if you're referring to the `dbch_handle` field in > `DEV_BROADCAST_HANDLE`, we already get that from the user using > `RegisterDeviceNotification`, and the current code just uses them for > sending notifications. I don't think adding custom structs is justified at this point, especially as it requires rewriting large parts of the code in multiple modules at the same time. > Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications. Fwiw I'm fine keeping the paths, and using the `reserved` field to describe them. I was just considering additional improvements but this specifically doesn't need to be done now. However, passing process-private handles around to other processes and later getting them back looks wrong. What happens if you register for notification on a handle then close it right away? Does the notification keep firing with the old handle value? It seem surprising and it would be a nice thing to test for instance. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80567

1 0