Hi Bruno, On Wed, Oct 9, 2019 at 4:09 PM Bruno Randolf <br1@xxxxxxxxxxx> wrote: > > On 03/10/2019 14:04, Luiz Augusto von Dentz wrote: > > Well I guess you are forgetting that other users of the GATT may > > interfere with plugin which is why we do the claim APIs in the first > > place. > > Okay, I understand your arguments from your perspective, which seems to > focus on specific use cases with Desktop Linux. > > But how do you suppose should application programmers or solution > providers access GATT characteristics under Linux in a predictable way > then? Not using BlueZ does not seem like a realistic option. Building > patched versions of bluetoothd isn't practical either. Right, so I assume then every application interested on battery would then attempt to subscribe for the battery level on the own instead of using org.bluez.Battery1? Either way that would be done via D-Bus but dealing with a characteristic seem quite a bit more expensive not to mention is another object the daemon has to maintain. > At the very least there should be a build option to deactivate all > plugins, but I think something more flexible would be better. Could it > be a user choice? E.g. only claim services which the User has actively > connected to and activated that service? There are runtime switches to disable plugins i.e.: bluetoothd -P battery and we can add build time switches as well, btw patches are welcome if you want to disable battery plugin. > In general I don't need to poll the battery status of every device I > happened to connect to, even though it might export a Battery service... > so I'd consider it more traffic if BAS is polled even though I didn't > ask for it. On the other hand on a Bluetooth device I have paired with, > something like a Headphone or Keyboard it obviously is the right choice. If the system don't have any need for battery it can disable it just like I said, but depending on the system it is probably better to leave the daemon to subscribe since there could be several applications interested on the battery status, simply reading org.bluez.Battery1 is a _lot_ simpler than enumerating all attributes and then subscribing to one characteristic. > I hope there is a way to support both use cases. There should be but it up for the system to decide if it wants a dedicated plugin to deal with the battery status or not, for the desktop usecase it is most likely simpler to support. > Regards, > bruno > > >> It surely makes sense to provide this more generic API, but I'd argue > >> that all services and characteristics should be available via the normal > >> GATT-based API using org.bluez.GattCharacteristic1 as well. > > > > Not if the service has security implication, for instance we don't > > want application to be able to access the keys presses coming from a > > HoG device, or other things like changing the settings bluetoothd has > > configured. > > > >> One of my clients, for example, uses Linux/bluez as an interface for > >> Server-based reading and writing of GATT characteristics of several > >> managed devices. So I can read all those UUIDs, but why not the battery > >> level? What happens when Bluez learns other GATT services, will their > >> characteristics then also disappear? I think there is a strong argument > >> for maintaining a generic API for GATT reading/writing characteristics > >> independently. > > > > But there is even a stronger argument if something breaks because the > > app access something it shouldn't, even if there are no conflicts > > between the plugin the very least it would cause is duplicating the > > traffic. > > > >> I made the following change to the bluetoothd code to get access again > >> to all UUIDs, and I would like you to consider to include it upstream to > >> enable us to access all characteristics via the normal GATT API: > >> > >> --- a/src/gatt-client.c > >> +++ b/src/gatt-client.c > >> @@ -2006,9 +2006,6 @@ static void export_service(struct > >> gatt_db_attribute *attr, void *user_data) > >> struct btd_gatt_client *client = user_data; > >> struct service *service; > >> > >> - if (gatt_db_service_get_claimed(attr)) > >> - return; > >> - > >> service = service_create(attr, client); > >> if (!service) > >> return; > >> > >> Thank you, > >> bruno > >> > >> > >> [1] I published parts of that as an open source library: > >> https://github.com/infsoft-locaware/blzlib > >> > >> [2] > >> https://stackoverflow.com/questions/49078659/check-battery-level-of-connected-bluetooth-device-on-linux > >> > >> > > > > -- Luiz Augusto von Dentz
