RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1694133 - Export the battery level advertised through AVRCP
Summary: Export the battery level advertised through AVRCP
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bluez
Version: 7.6
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: gopal krishna tiwari
QA Contact: Ken Benoit
URL:
Whiteboard:
Depends On:
Blocks: 1823697
TreeView+ depends on / blocked
 
Reported: 2019-03-29 15:16 UTC by Divya
Modified: 2023-10-06 18:12 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1823697 (view as bug list)
Environment:
Last Closed: 2020-04-14 10:04:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Divya 2019-03-29 15:16:07 UTC 
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.
Comment 1 Ray Strode [halfline] 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.
Comment 2 Bastien Nocera 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.
Comment 3 Bastien Nocera 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.
Comment 5 Bastien Nocera 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).
Comment 7 gopal krishna tiwari 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..
Comment 8 Andreas Bleischwitz 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
Comment 9 gopal krishna tiwari 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..
Comment 10 Ken Benoit 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).
Comment 11 gopal krishna tiwari 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..
Comment 12 Andreas Bleischwitz 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
Comment 13 gopal krishna tiwari 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
Comment 14 Andreas Bleischwitz 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
Comment 15 gopal krishna tiwari 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.
Comment 16 gopal krishna tiwari 2020-04-14 10:04:36 UTC 
(In reply to gopal krishna tiwari from comment #15)
> (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.

I've cloned the bz for for RHEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=1823697. Closing this one out as discussed in comment #12. Let's mover further discussion on RHEL-8 bugzilla. 

Gopal
Note You need to log in before you can comment on or make changes to this bug.