Closed kakra closed 6 years ago
The battery report is ID 04
, which is is only one byte long. The values i saw until now where always around 80-90. I will observe that and make some tests to find out the correct scale, should be easy then to include that.
The report descriptor says the (logical) range is between 0 and 255, I cannot confirm that - I think that it already turned off at around 80 once.
Usage Page (Generic Device Controls) 05 06
Usage (Battery Strength) 09 20
Logical Minimum (0) 15 00
Logical Maximum (255) 26 FF 00
Report Size (8) 75 08
Report Count (1) 95 01
Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit) 81 02
At least in Linux it behaves like the following:
Relatively full batteries are at 0x86
, it stops all rumbling effects at 0x84
, it shuts down before reaching 0x83
(for just a moment it becomes 0x04
- sometimes 0x06
).
I will have to: 1) Check if the behaviour is the same for windows 2) Check how the value is with new, full, quality batteries
Or maybe it is 0-10%, 10-50%, 50-90%, 90-100%?
It's the same behaviour in Windows
All Information above is only true for AA batteries! I will therefore impement this kind first, I think that the "play and charge"-battery differs a bit since it uses different connectors (at least for charging).
Started development: d8087aaf939077f0e885390a34aee34b84b1a0d8
Basic reports are implemented now, for everything else: let's open a new issue.
The module currently doesn't report that is has a battery sensor, and doesn't report battery events.
The original xpad driver can do this, tho it reported fresh and full batteries as only 50% full. So the new controller probably uses a different scale.