summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin
diff options
context:
space:
mode:
authorJose VillaseƱor Montfort <pepemontfort@gmail.com>2026-07-28 14:13:09 -0600
committerJiri Kosina <jkosina@suse.com>2026-08-03 20:38:09 +0200
commitd07644524b6511b622ee7b0e2e68c9ee43d522a4 (patch)
tree3649bb26bb354f0fec7df97cfa52ffd5ae75f3ef /tools/perf/scripts/python/bin
parentcdf826a94e0fef8dfc707967e8efee5571ca0f37 (diff)
HID: input: read battery capacity from its actual report offset
hidinput_query_battery_capacity() assumes the state-of-charge value is the first byte following the report ID (buf[1]) and ignores where the battery field actually sits within the report. An Apple Magic Trackpad 2 precedes the AbsoluteStateOfCharge byte with a byte of status flags in its battery reports, so this query returns the flags byte instead of the charge level. The device happens to make that easy to observe, because it exposes the same cell twice: its report descriptor declares AbsoluteStateOfCharge in two reports (0x90 and 0x9b), so hidinput_setup_battery() registers two power supplies. Only the first one is refreshed by hid-magicmouse -- it uses hid_get_battery(), which returns the first battery of the list -- and that refresh goes through the report event path, which parses the field correctly. Nothing ever reports the second one, so every read of its capacity takes the query path above. On a USB-C Magic Trackpad over USB, on an unpatched 7.1.5: hid-<serial>-battery-144 = 100% (Charging) <- report event path hid-<serial>-battery-155 = 3% (Discharging) <- query path Both are the same physical battery. A raw HIDIOCGINPUT of the two reports at that same moment: report 0x90 -> [90 03 64] report 0x9b -> [9b 03 64 64 00 00 10 00 00 00 00 00 00 00] ^flags ^SoC = 0x64 = 100% The device answers correctly in both cases; only the offset the kernel reads the capacity from is wrong. 0x03 is the flags byte (present, charging), reported as "3%". Bluetooth takes the same query path for its capacity, where the trackpad reported a bogus near-constant ~4% -- 0b100, the FullyCharged flag -- regardless of the real charge. Store the battery field's offset within the report at setup time and use it when querying, so the capacity is read from its real position. The report event path already parses the field correctly through the HID core; only the explicit GET_REPORT query was wrong. Devices whose capacity field is the first field in the report have a report_offset of 0 and are unaffected (buf[1 + 0] == buf[1]). Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Cc: stable@vger.kernel.org Signed-off-by: Jose VillaseƱor Montfort <pepemontfort@gmail.com> Reviewed-by: Alec Hall <signshop.alec@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions