search

atar-axis / xpadneo

Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)
https://atar-axis.github.io/xpadneo/
GNU General Public License v3.0
1.98k stars 112 forks source link

Wrong Batterylevel in Notification (always 50%) #342

Closed Chr1s70ph closed 2 years ago

Chr1s70ph commented 2 years ago

Version of xpadneo

Using the latest git-version (March 29th, 2022)

Controller Model

Connection mode

Installed Software

Severity / Impact

Describe the Bug

When connecting the controller, the battery level is displayed in the Dunst-Notification. It always displays 50% tho, no matter the actual charge state. Using blueman-manager, the correct battery level is displayed there. So the driver correctly reports the battery level, but the notification is sent, before xpadneo is fully loaded. (So I'm not even sure, if it is possible to fix).

Steps to Reproduce

Connect the Controller via bluetooth.

Expected Behavior

The correct battery value is displayed in the notification.

Screenshots / GIFs / Videos

image

System Information

# uname -a
Linux manjaro 5.16.14-1-MANJARO #1 SMP PREEMPT Fri Mar 11 14:12:18 UTC 2022 x86_64 GNU/Linux
# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0c 15 00 25 01 75 01 95 0c 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 04 81 03 05 0c 0a b2 00 15 00 25 01 95 01 75 01 81  u............%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0f 09 21 85 03 a1 02 09  ...%.u........!.....
000000c8: 97 15 00 25 01 75 04 95 01 91 02 15 00 25 00 75 04 95 01 91  ...%.u.......%.u....
000000dc: 03 09 70 15 00 25 64 75 08 95 04 91 02 09 50 66 01 10 55 0e  ..p..%du......Pf..U.
000000f0: 15 00 26 ff 00 75 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08  ..&..u.........&..u.
00000104: 95 01 91 02 65 00 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91  ....e.U..|..&..u....
00000118: 02 c0 c0                                                     ...
2986910699 1363

Controller and Bluetooth Information

xpadneo-btmon.txt xpadneo-dmesg.txt xpadneo-lsusb.txt

kakra commented 2 years ago

Please share the output of upower -d. It's probably showing (should be ignored) for the percentage level, in that case, the applet uses the wrong indicator. Xbox controllers don't support percentage levels but only discrete capacity levels:

Current BLE controllers seem to support battery reporting directly through the Bluetooth protocol - which probably applies to your controller. In that case, the driver should never ever report battery support by itself - so, no, in that case, it's not reported by xpadneo. But I haven't looked into that in detail, only noticed it a few weeks ago.

xpadneo is designed to only create a power supply device after it received the first battery report. If it didn't, it won't create a power supply. You can check if dmesg reports "battery detected" for xpadneo. If it does, upower -d should report a power supply device via xpadneo. If it doesn't, the battery info comes from bluez and xpadneo is not involved.

Chr1s70ph commented 2 years ago

It is showing the correct percentage, that is why I am confused:

Device: /org/freedesktop/UPower/devices/gaming_input_dev_F4_6A_D7_E6_73_BF
  native-path:          /org/bluez/hci0/dev_F4_6A_D7_E6_73_BF
  model:                Xbox Wireless Controller
  serial:               F4:6A:D7:E6:73:BF
  power supply:         no
  updated:              Di 29 Mär 2022 13:54:11 CEST (1 seconds ago)
  has history:          yes
  has statistics:       no
  gaming-input
    rechargeable:        no
    warning-level:       none
    percentage:          34%
    icon-name:          'battery-missing-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         no
  updated:              Di 29 Mär 2022 09:26:54 CEST (16038 seconds ago)
  has history:          no
  has statistics:       no
  unknown
    warning-level:       none
    percentage:          0%
    icon-name:          ''

Daemon:
  daemon-version:  0.99.17
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  no
  critical-action: PowerOff
kakra commented 2 years ago 
Device: /org/freedesktop/UPower/devices/gaming_input_dev_F4_6A_D7_E6_73_BF
  native-path:          /org/bluez/hci0/dev_F4_6A_D7_E6_73_BF

This native path is not coming from xpadneo, so the bug is somewhere else. xpadneo does not provide this battery level.

I suggest the bug is in the applet. We've seen some awkward interactions from TLP in the past. Do you have TLP installed? (https://linrunner.de/tlp/)

Chr1s70ph commented 2 years ago

We've seen some awkward interactions from TLP in the past. Do you have TLP installed?

Indeed I did. After uninstalling it (since I don't need it) and rebooting, it works as expected.

Chr1s70ph commented 2 years ago

It worked for the first time connection. But the 2nd time connecting, still shows 50%.

kakra commented 2 years ago

Does this change if you modprobe hid-xpadneo before connecting the controller?

Chr1s70ph commented 2 years ago

Does this change if you modprobe hid-xpadneo before connecting the controller?

Yes. modprobe hid_xpadneo results in 50% again. Rebooting, and connecting without modprobe displays the correct value again.

kakra commented 2 years ago

There's no indication in your dmesg that xpadneo is reporting battery events - otherwise there would be a line about that event. Thus, it is a third-party bug and should be reported to either the bluez or dunst-notification project. Since it depends on the order of loading modules, I'd say dunst-notification is to consider first, it may change behavior of what modules are loaded and what devices match.

Chr1s70ph commented 2 years ago

It might be that some higher level (HID, proprietary, whatever) setup finishes and causes the device to provide a different value

That is the closest I got to an answer why and where this issue comes from. I am still wondering, if I really am the only one with that problem, if so, then something on my end is not configured/set up correctly (and I don't know what).

kakra commented 2 years ago

I was able to test the new firmware and can confirm that battery is now reported directly through the Bluetooth protocol. It works correctly for me with KDE, so I suspect dunst-notification to have an issue on your side. But I didn't investigate that in regard to this issue report yet, it's just a first idea. I can also confirm that the battery reporting is not coming from HID because xpadneo doesn't get battery reports from the device with the new firmware. It's somehow handled in bluez.

Chr1s70ph commented 2 years ago

@kakra I am closing this issue, since it has been resolved in https://github.com/blueman-project/blueman/commit/1bd1a4af81879b4e6f604d8a536bd2bc18d984db and now works as expected.