Some clients may want to handle battery profile through the generic GATT
interface rather than BlueZ's internal Battery interface.
---
Makefile.plugins | 2 ++
configure.ac | 4 ++++
2 files changed, 6 insertions(+)
diff --git a/Makefile.plugins b/Makefile.plugins
index 98eee9ec8..b9733d31c 100644
--- a/Makefile.plugins
+++ b/Makefile.plugins
@@ -101,8 +101,10 @@ builtin_cppflags += $(ALSA_CFLAGS)
builtin_ldadd += $(ALSA_LIBS)
endif
+if BATTERY
builtin_modules += battery
builtin_sources += profiles/battery/battery.c
+endif
if SIXAXIS
plugin_LTLIBRARIES += plugins/sixaxis.la
diff --git a/configure.ac b/configure.ac
index 1433ace4a..d4fa862b5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -181,6 +181,10 @@ AC_ARG_ENABLE(hog, AC_HELP_STRING([--disable-hog],
[disable HoG profile]), [enable_hog=${enableval}])
AM_CONDITIONAL(HOG, test "${enable_hog}" != "no")
+AC_ARG_ENABLE(battery, AC_HELP_STRING([--disable-battery],
+ [disable battery profile]), [enable_battery=${enableval}])
+AM_CONDITIONAL(BATTERY, test "${enable_battery}" != "no")
+
AC_ARG_ENABLE(health, AC_HELP_STRING([--enable-health],
[enable health profiles]), [enable_health=${enableval}])
AM_CONDITIONAL(HEALTH, test "${enable_health}" = "yes")
--
2.17.1
Hi Sonny,
> Some clients may want to handle battery profile through the generic GATT
> interface rather than BlueZ's internal Battery interface.
> ---
> Makefile.plugins | 2 ++
> configure.ac | 4 ++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/Makefile.plugins b/Makefile.plugins
> index 98eee9ec8..b9733d31c 100644
> --- a/Makefile.plugins
> +++ b/Makefile.plugins
> @@ -101,8 +101,10 @@ builtin_cppflags += $(ALSA_CFLAGS)
> builtin_ldadd += $(ALSA_LIBS)
> endif
>
> +if BATTERY
> builtin_modules += battery
> builtin_sources += profiles/battery/battery.c
> +endif
>
> if SIXAXIS
> plugin_LTLIBRARIES += plugins/sixaxis.la
> diff --git a/configure.ac b/configure.ac
> index 1433ace4a..d4fa862b5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -181,6 +181,10 @@ AC_ARG_ENABLE(hog, AC_HELP_STRING([--disable-hog],
> [disable HoG profile]), [enable_hog=${enableval}])
> AM_CONDITIONAL(HOG, test "${enable_hog}" != "no")
>
> +AC_ARG_ENABLE(battery, AC_HELP_STRING([--disable-battery],
> + [disable battery profile]), [enable_battery=${enableval}])
> +AM_CONDITIONAL(BATTERY, test "${enable_battery}" != "no")
> +
> AC_ARG_ENABLE(health, AC_HELP_STRING([--enable-health],
> [enable health profiles]), [enable_health=${enableval}])
> AM_CONDITIONAL(HEALTH, test "${enable_health}" = "yes")
I have a little bit concern splitting this since battery service and HoG are kinda connected. Wouldn’t it be better we have a cleaner interface. Maybe we should actually integrate cleanly with /dev/upower or similar.
Regards
Marcel
Hi Marcel,
On Wed, May 6, 2020 at 7:24 AM Marcel Holtmann <[email protected]> wrote:
>
> Hi Sonny,
>
> > Some clients may want to handle battery profile through the generic GATT
> > interface rather than BlueZ's internal Battery interface.
> > ---
> > Makefile.plugins | 2 ++
> > configure.ac | 4 ++++
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/Makefile.plugins b/Makefile.plugins
> > index 98eee9ec8..b9733d31c 100644
> > --- a/Makefile.plugins
> > +++ b/Makefile.plugins
> > @@ -101,8 +101,10 @@ builtin_cppflags += $(ALSA_CFLAGS)
> > builtin_ldadd += $(ALSA_LIBS)
> > endif
> >
> > +if BATTERY
> > builtin_modules += battery
> > builtin_sources += profiles/battery/battery.c
> > +endif
> >
> > if SIXAXIS
> > plugin_LTLIBRARIES += plugins/sixaxis.la
> > diff --git a/configure.ac b/configure.ac
> > index 1433ace4a..d4fa862b5 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -181,6 +181,10 @@ AC_ARG_ENABLE(hog, AC_HELP_STRING([--disable-hog],
> > [disable HoG profile]), [enable_hog=${enableval}])
> > AM_CONDITIONAL(HOG, test "${enable_hog}" != "no")
> >
> > +AC_ARG_ENABLE(battery, AC_HELP_STRING([--disable-battery],
> > + [disable battery profile]), [enable_battery=${enableval}])
> > +AM_CONDITIONAL(BATTERY, test "${enable_battery}" != "no")
> > +
> > AC_ARG_ENABLE(health, AC_HELP_STRING([--enable-health],
> > [enable health profiles]), [enable_health=${enableval}])
> > AM_CONDITIONAL(HEALTH, test "${enable_health}" = "yes")
>
> I have a little bit concern splitting this since battery service and HoG are kinda connected. Wouldn’t it be better we have a cleaner interface. Maybe we should actually integrate cleanly with /dev/upower or similar.
I agree, we are re-evaluating this.
>
> Regards
>
> Marcel
>
On Wed, 2020-05-06 at 13:24 +0200, Marcel Holtmann wrote:
> I have a little bit concern splitting this since battery service and
> HoG are kinda connected. Wouldn’t it be better we have a cleaner
> interface. Maybe we should actually integrate cleanly with
> /dev/upower or similar.
Wat?
Hi Marcel, Bastien,
On Wed, May 6, 2020 at 7:14 AM Bastien Nocera <[email protected]> wrote:
>
> On Wed, 2020-05-06 at 13:24 +0200, Marcel Holtmann wrote:
> > I have a little bit concern splitting this since battery service and
> > HoG are kinda connected. Wouldn’t it be better we have a cleaner
> > 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.
--
Luiz Augusto von Dentz
Hi Luiz,
>>> I have a little bit concern splitting this since battery service and
>>> HoG are kinda connected. Wouldn’t it be better we have a cleaner
>>> 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.
I thought we had created a /dev/upower to create battery information. Maybe it was just /dev/uleds and the other one was left up in the air.
Regards
Marcel
Hi Sonny,
On Wed, May 6, 2020 at 9:35 AM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Marcel, Bastien,
>
> On Wed, May 6, 2020 at 7:14 AM Bastien Nocera <[email protected]> wrote:
> >
> > On Wed, 2020-05-06 at 13:24 +0200, Marcel Holtmann wrote:
> > > I have a little bit concern splitting this since battery service and
> > > HoG are kinda connected. Wouldn’t it be better we have a cleaner
> > > 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
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
<[email protected]> wrote:
>
> Hi Sonny,
>
> On Wed, May 6, 2020 at 9:35 AM Luiz Augusto von Dentz
> <[email protected]> wrote:
> >
> > Hi Marcel, Bastien,
> >
> > On Wed, May 6, 2020 at 7:14 AM Bastien Nocera <[email protected]> wrote:
> > >
> > > On Wed, 2020-05-06 at 13:24 +0200, Marcel Holtmann wrote:
> > > > I have a little bit concern splitting this since battery service and
> > > > HoG are kinda connected. Wouldn’t it be better we have a cleaner
> > > > 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
Hi Luiz,
>>> On Wed, 2020-05-06 at 13:24 +0200, Marcel Holtmann wrote:
>>>> I have a little bit concern splitting this since battery service and
>>>> HoG are kinda connected. Wouldn’t it be better we have a cleaner
>>>> 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.
lets wait and see if we can actually generalize this feature.
Regards
Marcel