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.
--
v26: 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
ole32: fixed incorrect write dword high part datetime to buffer with OFFSET_PS_MTIMEHIGH in UpdateRawDirEntry
@Mystral, @julliard, @hans, I think this is higher priority for code review than my previous PRs.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6710
This reverts commit b3eb55227aef198a637f80a2fa0bce74aa0a7190.
Since 278b98f5b21b56abdf9229b12b2a747be6917018 it should be unnecessary to
process the events as the current display mode is written to the registry.
This fixes a random deadlock that happens when a window is updating its state
while another thread changes the current display settings.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6701