+++ This bug was initially created as a clone of Bug #1694133 +++

Description of problem:
Many bluetooth devices support the BAS service of the GATT profile, which allows the host to retrieve the battery level of an attached device (eg. head set or keyboard). In many cases this is the only way to get any information about the battery level of that devices. gnome should display that information in the panel.

Version-Release number of selected component (if applicable):
control-center-3.28.1-4.el7

How reproducible:
Always

Steps to Reproduce:
1. pair a bluetooth device to a RHEL-7.6 system.

Actual results:
Battery information of the bluetooth device is not displayed.

Expected results:
Battery information of the bluetooth device should appear in the panel

Additional info:
As per issue at https://gitlab.gnome.org/GNOME/gnome-control-center/issues/224, looks like it has been implemented in latest gnome-control-center upstream.

— Additional comment from Ray Strode [halfline] on 2019-03-29 15:26:51 UTC —

I actually suspect this feature is already implemented in 7.6, so maybe there needs to be some lower level fix in bluez or upower, but i'm not sure.

Bastien would know, though, so CCing him.

— Additional comment from Bastien Nocera on 2019-04-03 10:41:30 UTC —

(In reply to Ray Strode [halfline] from comment #1)
> I actually suspect this feature is already implemented in 7.6, so maybe
> there needs to be some lower level fix in bluez or upower, but i'm not sure.

http://www.hadess.net/2017/12/more-bluetooth-and-gaming-features.html

You need a new enough bluez (5.48) and upower (0.99.7). The devices would them show in the power panel.

— Additional comment from Bastien Nocera on 2019-04-16 15:20:24 UTC —

Can you please check about which exact hardware this bug is, and whether the devices do indeed use Bluetooth LE and the BAS GATT service to advertise to the battery information?

The title is really wide, comment 0 a little more narrow.

— Additional comment from Divya on 2019-05-01 03:52:15 UTC —

Response from customer:

I checked the device (ISY IBH-6500). It does not advirtise the necessary profiles, so either Android uses a different way (eg. the extended Hands-Free profile that Apple proposed) or it is reporting fake values.

— Additional comment from Bastien Nocera on 2019-05-02 12:28:28 UTC —

The device in question is an ISY IBH-6500:
https://www.saturn.de/de/product/_isy-ibh-6500-bk-2364904.html

If it reports the battery level correctly on Android, then it probably uses the AVCRP
battery reporting features.

See https://gitlab.freedesktop.org/upower/upower/issues/38 for more detailed information.

I'll reassign this to bluez, as I think that the feature is implementable now that there
is a way for bluez to export battery state in a way that upower can consume
(org.bluez.Battery1).

— Additional comment from Andreas Bleischwitz on 2019-12-05 13:10:39 UTC —

Is there any activity which I could report to my customer? This BZ is open for some time now, without any visible progress.

Customer:
Account Name Commerzbank AG
Account Number 315059
Strategic Yes
Has TAM Yes
Has CSM No

— Additional comment from gopal krishna tiwari on 2020-03-04 08:09:28 UTC —

Hi,

Apologize for the delay ..

Would it be possible for you to verify if I back port the required patches to the RHEL-7 bluez package ?

Gopal..

— Additional comment from Andreas Bleischwitz on 2020-03-04 09:07:03 UTC —

Hi Gopal,

my customer reported that he is now using RHEL8 on his machine, so backporting would not provide that much of improvement.
Taken into account that battery levels seem to be reported using AVCRP nowadays, I'm not sure whether it would help other users that much.

/Andreas

— Additional comment from gopal krishna tiwari on 2020-03-04 10:19:55 UTC —

(In reply to Andreas Bleischwitz from comment #8)
> Hi Gopal,
>
> my customer reported that he is now using RHEL8 on his machine, so
> backporting would not provide that much of improvement.
> Taken into account that battery levels seem to be reported using AVCRP
> nowadays, I'm not sure whether it would help other users that much.
>
> /Andreas

What should we do here ?. I am afraid backport anything without testing at this stage of RHEL-7 can create lot of other issues. Please let me know your opinion.

Gopal..

— Additional comment from Ken Benoit on 2020-03-04 11:50:12 UTC —

(In reply to gopal krishna tiwari from comment #9)
> What should we do here ?. I am afraid backport anything without testing at
> this stage of RHEL-7 can create lot of other issues. Please let me know your
> opinion.
>

7.8 is almost out the door. If anything, this is going into a 7.8 z-stream (unlikely) or 7.9 (more likely).

— Additional comment from gopal krishna tiwari on 2020-03-04 11:52:31 UTC —

(In reply to Ken Benoit from comment #10)
> (In reply to gopal krishna tiwari from comment #9)
> > What should we do here ?. I am afraid backport anything without testing at
> > this stage of RHEL-7 can create lot of other issues. Please let me know your
> > opinion.
> >
>
> 7.8 is almost out the door. If anything, this is going into a 7.8 z-stream
> (unlikely) or 7.9 (more likely).

Yeah, I agree.

Gopal..

— Additional comment from Andreas Bleischwitz on 2020-03-05 15:41:29 UTC —

Gopal,

I don't think it would make sense to backport something which is of that little use. This kind of feature would more likely bee useful when using desktops rather servers.
And as desktops are more likely to get updated to RHEL8, I don't think it's worth the efforts to backport to RHEL7.

By looking at the upstream issue (https://gitlab.freedesktop.org/upower/upower/issues/38), I don't see any progress. Is there a solution for AVCRP in place already?
This would be something worth to be backported to bluez (RHEL8).

Hope that clarifies my points.

/Andreas

— Additional comment from gopal krishna tiwari on 2020-03-06 04:39:23 UTC —

(In reply to Andreas Bleischwitz from comment #12)
> Gopal,
>
> I don't think it would make sense to backport something which is of that
> little use. This kind of feature would more likely bee useful when using
> desktops rather servers.
> And as desktops are more likely to get updated to RHEL8, I don't think it's
> worth the efforts to backport to RHEL7.
>
> By looking at the upstream issue
> (https://gitlab.freedesktop.org/upower/upower/issues/38), I don't see any
> progress. Is there a solution for AVCRP in place already?
> This would be something worth to be backported to bluez (RHEL8).
>
> Hope that clarifies my points.
>
> /Andreas

Hi Andreas,

Would encourage you to please try and verify over RHEL-8. As RHEL-8 is over bluez-5.50+ version Upstream. If in case we are missing anything there I can re-sync bluez. For now if you are fine can we close this bz ?. Please feel free to open another bz for RHEL-8.

Thanks
Gopal

— Additional comment from Andreas Bleischwitz on 2020-03-06 08:23:15 UTC —

Hi Gopal,

I just tested with bluez-5.53-2.fc31.x86_64 and haven't been able to find any power information being reported after pairing with a device which does report power on i.e. my phone.

RHEL8's version of bluez is 5.50, so I assume it's lacking this functionality as well.

Wouldn't it make sense to clone this BZ for RHEL8, closing this one? This way we wouldn't loose the conversation which is still valid for RHEL8.

If you would provide me instructions to provide further details which would lead to an implementing of that functionality, I'm happy to share.

Best regards,

/Andreas

— Additional comment from gopal krishna tiwari on 2020-03-09 05:43:34 UTC —

(In reply to Andreas Bleischwitz from comment #14)
> Hi Gopal,
>
> I just tested with bluez-5.53-2.fc31.x86_64 and haven't been able to find
> any power information being reported after pairing with a device which does
> report power on i.e. my phone.
>
> RHEL8's version of bluez is 5.50, so I assume it's lacking this
> functionality as well.
>
> Wouldn't it make sense to clone this BZ for RHEL8, closing this one? This
> way we wouldn't loose the conversation which is still valid for RHEL8.
>
> If you would provide me instructions to provide further details which would
> lead to an implementing of that functionality, I'm happy to share.
>
> Best regards,
>
> /Andreas

Hi Andreas,

Thanks for your prompt response. Sure we can clone this bz for RHEL-8 as well. bluez-5.53 is where upstream also working on. Will let you know surely in case I need any help.

Thanks,
Gopal.