> -----Original Message----- > From: Luiz Augusto von Dentz [mailto:luiz.dentz@xxxxxxxxx] > > I was fearing that. Such is life ... I will find some heuristics here. Thank you. > > You can check how d-feet does to retrieve the pid and binary path, > than you can issue a --version to it and parse the output. Thank you for the hint. I will check it out. > >> Btw, if you are looking for other hints you could try bind/listen on GATT cid, > as > >> far GATT goes this should indicate bluetoothd is listening on it. > > > > That's what my existing alternative backend connects to and where I ran an > entire (G)ATT stack. Obviously, this completely bypasses bluetoothd (that's the > stack I want to swap out if bluetoothd is recent enough). What I don't > understand is how this could help me to figure out what version of bluetoothd is > running. The test to check whether Bluetooth is running is doable via dbus > already and less of a problem. I there a correlation between bluetoothd version > and bluetoothd always being connected to the GATT cid? What am I missing? > > Which an application was never supposed to do, specially when we are > talking about a fixed channel, but I guess you are know learning it > the hard way. I knew that from the beginning. Problem is that Qt had to support BTLE from Bluez 4.101 onwards. Only now that Bluez is finally catching up (still not there yet) I can consider shifting the burden. > What I was suggesting is detect if bluetoothd is already > handling the ATT cid but perhaps that is not enough given there are > many versions where the GATT implementation may not be fully > operational or is still marked experimental. >From what I can tell this is only true if a connection to a remote device exists, right? At least my tests show that the socket connection is not always open. > If I where to make this changes I would just remove any implementation > of GATT/ATT and start over depending on the upcoming BlueZ release > which should cover both central and peripheral roles, but perhaps you > cannot do that because that would leave systems that cannot update > BlueZ unable to update Qt as well. If life would always this easy... You guessed right. I cannot cut support for Bluez versions below 5.42 (first version of Bluez that had non-experimental BTLE APIs). Second reason is that especially on the peripheral side Bluez is still experimental and some things such as various advertising parameters (e.g. white lists & intervals) are not available yet. Especially the intervals are a big problems (hint hint 😉). For the time being I have to run both stacks - but Bluez and Qt will get there. -- Alex ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
