Hi Luiz, On Mon, Sep 9, 2024 at 8:47 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Is this the best format though? I'm afraid this would require an upper > level to implement SDP record parsing as well or is that what Windows > exposes as well? Yes, the service discovery related interfaces on Windows return a raw SDP byte stream, which the user is expected to further parse with methods like BluetoothSdpEnumAttributes[1]. That being said, my primary motivation for returning the raw SDP data was to also discourage other applications from using this instead of the Profile API. Essentially, the Windows kernel and usermode Bluetooth APIs let you make SDP queries to Bluetooth devices (including service and service + attribute queries). From my understanding, exposing raw SDP is an antipattern in BlueZ that was discarded with BlueZ 5, so I did not want to re-introduce the entire concept again over DBus. Instead, the current design of the Wine bluetooth driver is to rely on the cached records stored by BlueZ, and perform any and all queries by searching through them. The other option was to rely on sdp_lib.h, but having two SDP local servers (is it a local server if it's only being used for device queries?) for every machine sounds like a recipe for eventual breakage, and letting BlueZ be the authoritative source of truth for device-related information is a common pattern in Wine. [1]: https://learn.microsoft.com/en-us/windows/win32/api/bluetoothapis/nf-bluetoothapis-bluetoothsdpenumattributes -- Vibhav Pant vibhavp@xxxxxxxxx GPG: 7ED1 D48C 513C A024 BE3A 785F E3FB 28CB 6AB5 9598
