Hi Andreas, 

Can you please check and verify over upstream bluez version which is currently 5.54. If it works I'll re-sync it with rhel-8.3. 

Thanks 
Gopal

Hi Gopal,

I tested on bluez-5.54-1.fc31.x86_64 and did not see any power reported by my bluetooth device.

I will attach Teufel-Real-Blue-NC-power-on.pcapng with a packet dump taken during power-on and power-off of that device.
Hope it helps.

Best regards,

/Andreas

Hi Andreas, 

I've checked the code for bluez seems like we have support for AVRCP and could see the patches also available. We probably have to check are there any configuration changes require or the device does support that or not ?. 

Can you help me out with some bluez debug logs as well as with the packet dump ? 

Another can you help me with the method you are testing with so that I also can try at my end.

Thanks 
Gopal

Hi Gopal,

sorry for coming back to you late.

Yes for sure I would assist where ever possible. I just found that I may be able to provide some bluetooth dumps from my mobile which does show the battery-level.

My testing had been limited to pairing a bluetooth device (headset in my case) which does report it's battery-level on a mobile-phone. After the device was connected, I checked whether there was an entry visible in the "power" tab of gnome-settings - which was not.

If you would provide further advise how to provide logs/dumps/states, I'm happy to help.

Thanks
/Andreas

(In reply to Andreas Bleischwitz from comment #5)
> Hi Gopal,
> 
> sorry for coming back to you late.
> 
> Yes for sure I would assist where ever possible. I just found that I may be
> able to provide some bluetooth dumps from my mobile which does show the
> battery-level.
> 
> My testing had been limited to pairing a bluetooth device (headset in my
> case) which does report it's battery-level on a mobile-phone. After the
> device was connected, I checked whether there was an entry visible in the
> "power" tab of gnome-settings - which was not.
> 
> If you would provide further advise how to provide logs/dumps/states, I'm
> happy to help.
> 
> Thanks
> /Andreas

Thanks Andreas, 

1) How to ? 

$ \<edit\> /usr/lib/systemd/system/bluetooth.service
\<add '-d' to ExecStart line as option to bluetoothd\> as follows :

ExecStart=/usr/libexec/bluetooth/bluetoothd -d 

\<save and quit\>

$ systemctl daemon-reload
$ systemctl restart bluetooth

To capture the log

$ journalctl -r -u bluetooth > output_to_a_file.log 

2) In parallel you can start btmon capture as well.

Please share out put of both.  

Gopal..

Hi Gnome-bluetooth team, 

Do you suggest any application which display's bluetooth-battery level or support bluetooth battery level ? or can you help me in approaching to the right team ? 

Thanks 
Gopal Tiwari

(In reply to gopal krishna tiwari from comment #16)
> Hi Gnome-bluetooth team, 
> 
> Do you suggest any application which display's bluetooth-battery level or
> support bluetooth battery level ? or can you help me in approaching to the
> right team ? 

Sorry, I don't understand what's being asked here. If the battery information
isn't exported, then there will be nothing to show it.

Did you figure out which battery protocol the headset uses?

(In reply to Bastien Nocera from comment #17)
> (In reply to gopal krishna tiwari from comment #16)
> > Hi Gnome-bluetooth team, 
> > 
> > Do you suggest any application which display's bluetooth-battery level or
> > support bluetooth battery level ? or can you help me in approaching to the
> > right team ? 
> 
> Sorry, I don't understand what's being asked here. If the battery information
> isn't exported, then there will be nothing to show it.
> 
> Did you figure out which battery protocol the headset uses?

As far as I could read Gatt doesn't have anything related to battery profile. So I am assuming avrcp as I can see from journalctl logs its mostly dealing in avrcp code path. Let me know if I missing anything.

Gopal

(In reply to gopal krishna tiwari from comment #18)
<snip>
> As far as I could read Gatt doesn't have anything related to battery
> profile. So I am assuming avrcp as I can see from journalctl logs its mostly
> dealing in avrcp code path. Let me know if I missing anything.

You need to find out what battery protocol is used, then implement said battery level
reading in the right place, depending on that protocol.

This issue has some hints:
https://gitlab.freedesktop.org/upower/upower/-/issues/38

There's nothing to be done in gnome-bluetooth, and unfortunately, I don't have the time
nor the hardware to look into this myself so I'll reassign to bluez.

(In reply to Bastien Nocera from comment #19)
> (In reply to gopal krishna tiwari from comment #18)
> <snip>
> > As far as I could read Gatt doesn't have anything related to battery
> > profile. So I am assuming avrcp as I can see from journalctl logs its mostly
> > dealing in avrcp code path. Let me know if I missing anything.
> 
> You need to find out what battery protocol is used, then implement said
> battery level
> reading in the right place, depending on that protocol.
> 
> This issue has some hints:
> https://gitlab.freedesktop.org/upower/upower/-/issues/38
> 
> There's nothing to be done in gnome-bluetooth, and unfortunately, I don't
> have the time
> nor the hardware to look into this myself so I'll reassign to bluez.

Sure, will try. So what I understood upower will display once we have things in place.

Gopal

(In reply to gopal krishna tiwari from comment #20)
<snip>
> Sure, will try. So what I understood upower will display once we have things
> in place.

If, and only if, that battery information is exported through the org.bluez.Battery1
interface in bluez. There's currently no support for any other type of battery reporting
in any other parts of the stack.

(In reply to Bastien Nocera from comment #21)
> (In reply to gopal krishna tiwari from comment #20)
> <snip>
> > Sure, will try. So what I understood upower will display once we have things
> > in place.
> 
> If, and only if, that battery information is exported through the
> org.bluez.Battery1
> interface in bluez. There's currently no support for any other type of
> battery reporting
> in any other parts of the stack.

Ok sure, I've checked if we have this interface supported mostly with the hardware I have but I am getting 

 "No such interface 'org.bluez.Battery1'". 

Gopal

This bug is scheduled for migration to Jira.  When that happens, this bugzilla issue will be permanently closed with the status MIGRATED and all future interaction on this issue will need to happen in the Jira issue.  The new issue will be part of the RHEL project (a project for Jira only issues, which will sync once, then close the bugzilla issue and all future updates will happen in Jira), not part of the RHELPLAN project (which is part of the automated bugzilla->Jira mirroring and which allows ongoing updates to the bugzilla bug and syncs those updates over to Jira).

For making sure you have access to Jira in order to continue accessing this issue, follow one of the appropriate knowledge base articles:

KB0016394 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394
KB0016694 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694
KB0016774 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774

For general issues with Jira, open a ticket with rh-issues

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.

Additional information on creating a Jira account to access the migrated issue can be found here:

https://access.redhat.com/articles/7032570