Hi Alex, On Thu, Nov 2, 2017 at 10:47 AM, Alex Blasche <alexander.blasche@xxxxx> wrote: > Hi Luiz, > >> -----Original Message----- >> From: Luiz Augusto von Dentz [mailto:luiz.dentz@xxxxxxxxx] > >> While I understand what you are at adding the version would only affect >> upcoming releases so I don't how it would fix the problem. > > Ok, there is nothing. Might I ask for a new version tag somewhere? After all API's will always be added or changed. It would be an investment into the future. > >> > The only reliable way I have seen so far is bluetoothd --version which assumes >> that one knows where bluetoothd is located. At least in source I could not find >> any other way. > > 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. >> 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. 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. 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. > -- > Alex > > -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
