Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200501215352.23858-1-sonnysasaka@chromium.org>
 <4A9E7F0B-4AB8-4330-BB2B-1A0EAA4EFDE8@holtmann.org> <a4650a5e465c23915d951b296ca86de9f2d91b44.camel@hadess.net>
 <CABBYNZK2SwcOO0jdpvtcdyjHFzw=WNocRU-a37hRsK3=yJ+d3Q@mail.gmail.com> <CABBYNZJu7Jg2fjZaJpR8S7iN6JSy4FYKjKZ2FN5mtKvLwSJywQ@mail.gmail.com>
In-Reply-To: <CABBYNZJu7Jg2fjZaJpR8S7iN6JSy4FYKjKZ2FN5mtKvLwSJywQ@mail.gmail.com>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Wed, 6 May 2020 10:18:11 -0700
Message-ID: <CAOxioN=LO3EsK0CPe8W+s-o-Xzs0xH6EfbTFLutUOsbJ5-uEkQ@mail.gmail.com>
Subject: Re: [PATCH] build: Add option to disable battery profile
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     Bastien Nocera <hadess@hadess.net>,
        Marcel Holtmann <marcel@holtmann.org>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Marcel/Luiz,

Thanks for the feedback. We in Chrome OS are going to re-evaluate the
need for this, so we can hold off the decision for now. Generally,
these are some aspects we want to consider:
* For Chrome OS, we already have a working code for battery indicator
via BlueZ's general GATT API, but it's much simpler to just use
BlueZ's internal battery service API for our battery indicator
feature. If we can migrate to this, we don't need this build option.
* For other platforms, I think it's good to have more control over
what profiles are handled internally by BlueZ, since they may want to
use the profile directly and they can't do that if BlueZ monopolizes
the profile. There may also be some needs to do this on Chrome OS
actually, since Web Bluetooth has some sample use cases to read
Battery Level (https://googlechrome.github.io/samples/web-bluetooth/battery=
-level.html).

We will discuss those and other factors first and let you know whether
we need this patch. Thanks again for the responses!

On Wed, May 6, 2020 at 9:44 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Sonny,
>
> On Wed, May 6, 2020 at 9:35 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Marcel, Bastien,
> >
> > On Wed, May 6, 2020 at 7:14 AM Bastien Nocera <hadess@hadess.net> wrote=
:
> > >
> > > On Wed, 2020-05-06 at 13:24 +0200, Marcel Holtmann wrote:
> > > > I have a little bit concern splitting this since battery service an=
d
> > > > HoG are kinda connected. Wouldn=E2=80=99t it be better we have a cl=
eaner
> > > > interface. Maybe we should actually integrate cleanly with
> > > > /dev/upower or similar.
> > >
> > > Wat?
> >
> > I guess Marcel was refering to something like uhid though Im not sure
> > that exists, or does it? That said one alternative would make uhid
> > integrate the battery status, but I guess devices can also expose this
> > over hid directly so I wonder if we can translate the Battery Service
> > status to hid power strength that way we don't need any communication
> > over D-Bus.
>
> Btw, Im fine with the option to disable building the battery plugin
> since platforms may not have a use for it, so except if there are some
> strong reason against it I will apply the patch.
>
> --
> Luiz Augusto von Dentz