Hi Vibhav, On Mon, Sep 9, 2024 at 12:36 PM Vibhav Pant <vibhavp@xxxxxxxxx> wrote: > > On Mon, Sep 9, 2024 at 9:00 PM Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: > > > > Hi Vibhav, > > > > Don't really like where this is going, if we need bearer specific API > > like this then we need a whole new interface, besides you didn't > > really explain the reason why you needed this, is that to determine if > > there are SDP records to be fetched? > > ConnectionType is needed only to differentiate between LE and BR/EDR > devices. This is because the NT kernel creates device objects for > every discovered Bluetooth device, and BR/EDR and LE devices exist > under different paths/hierarchies (I suppose the equivalent would be > BR/EDR devices existing under /dev/bluetooth/devices/bredr, and LE > devices under /dev/bluetooth/devices/le). Essentially, BR/EDR and LE > devices can be differentiated in several significant ways, and I could > not find a way to reliably do that. The current code checks if > AddressType is random, otherwise tries to see if the device object has > org.bluez.Gatt* interfaces to determine if the connection bearer is > LE. However, I understand that's not reliable, and doesn't determine > if the device is connected using dual-mode. > > That being said, Bearer does sound like a better name for the > property, and I can modify the patch to that effect. However, I don't > foresee the need for a ConnectBearer property for Wine. Ultimately, my > goal is to implement Bluetooth functionality with the minimum possible > API surface added to BlueZ, hence the small (ish) patches. Ive left this out for now, we can revisit this if we find out that it is really necessary in the future. Btw, how is the wine support going, perhaps we can put something under doc or in the guthub wiki about the compatibility with windows. > -- > Vibhav Pant > vibhavp@xxxxxxxxx > GPG: 7ED1 D48C 513C A024 BE3A 785F E3FB 28CB 6AB5 9598 -- Luiz Augusto von Dentz
