Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <a04053d3-6165-5dfa-932c-5a93d2bd1358@einfach.org>
 <CABBYNZLK_rzAf5aPzJHShEVvXSvndZFh5TjyjaaFzAPw_sHoTA@mail.gmail.com> <12b16466-3633-75ff-bf84-9cef44a2358c@einfach.org>
In-Reply-To: <12b16466-3633-75ff-bf84-9cef44a2358c@einfach.org>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Wed, 9 Oct 2019 16:34:57 +0300
Message-ID: <CABBYNZKUmctzTRxix9P-FBK=15v01tkHWMCirFefStpCS2ukBQ@mail.gmail.com>
Subject: Re: bluetoothd: Please don't filter UUIDs
To:     Bruno Randolf <br1@einfach.org>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Bruno,

On Wed, Oct 9, 2019 at 4:09 PM Bruno Randolf <br1@einfach.org> 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