| Message ID | 20200501215352.23858-1-sonnysasaka@chromium.org (mailing list archive) |
|---|---|
| State | Deferred |
| Delegated to: | Marcel Holtmann |
| Headers | show |
| Series | build: Add option to disable battery profile | expand |
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 <marcel@holtmann.org> 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 <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 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.
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 <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 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.
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 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
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")