I'm not sure if it's the best way of fixing the bug. I was trying to set compilation options to workaround the problem but it didn't work well (probably due to my limited knowledge in this area).
The patch was originally sent in !5276.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6668
This is my last set of patches changing DDS pixel format handling.
--
v2: d3dx9: Add support for more DDS pixel formats.
d3dx9: Rework conversion to/from D3DFORMAT from/to DDS pixel format.
d3dx9: Validate the size of DDS files containing packed pixel formats.
d3dx9/tests: Add file size validation tests for DDS files containing packed pixel formats.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6653
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.
--
v7: 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
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.
--
v12: 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
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.
--
v13: 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.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6621