kernel/git/stable/linux.git/drivers/hid/hid-input.c, branch master

Merge branch 'for-7.3/core' into for-linus

2026-08-19T07:27:26+00:00

- fix long-standing force-feedback initialization race across the subsystem (Dmitry Torokhov) - switch to system_dfl_wq (Marco Crivellari)

HID: move generic FF initialization into hidinput_connect()

2026-08-14T12:46:21+00:00

Generic force-feedback initialization (pidff) currently happens in hid_connect() after hidinput_connect() has already registered the input devices. This is racy as the device is live and visible to userspace before FF support is fully set up. Move the call to hdev->ff_init() into hidinput_connect(), ensuring it runs before input_register_device() is called. This closes the race window for standard PID-capable devices. The initialization now also checks (connect_mask & HID_CONNECT_FF) and !hid_has_ff_input() to avoid conflicts with custom FF implementations and respect driver opt-outs. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina

HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-C

2026-08-03T19:02:55+00:00

The Apple Magic Trackpad 2 (USB-C) reports a wildly wrong battery capacity over Bluetooth, for example a constant 4% for a pack that is actually at 74%. The device's battery input report (0x90) is laid out as [report-id][status][charge]. hid-input's synchronous capacity query, hidinput_query_battery_capacity(), assumes the common [report-id][capacity] layout and returns buf[1], which for this device is the status byte rather than the charge (buf[2]). magicmouse_fetch_battery(), which requests the battery report through hid_hw_request() so the reply is decoded via the report descriptor at the correct field offset, is gated to the USB models and never runs over Bluetooth. The device does not push battery reports on its own either, except a single one at connect time, which is delivered while probe holds driver_input_lock and is silently dropped. All userspace reads therefore go through the misparsing query, and the device is stuck reporting its status byte as the capacity. Enabling the fetch for Bluetooth is not sufficient on its own: user space reacts to the power_supply registration immediately, so a query is typically already in flight when the fetch reply is parsed. hidinput_get_battery_property() stores the query result and marks the battery as queried without rechecking whether a report arrived while it was waiting, clobbering the just-reported correct value with the misparsed one. Fix this by adding HID_BATTERY_QUIRK_AVOID_QUERY for the Bluetooth Magic Trackpad USB-C so the misparsing query path is never used, and by fetching the battery at the end of probe for this device. hidp has no asynchronous request() callback, so the fetch is serviced synchronously via __hid_request() while probe still holds driver_input_lock; call hid_device_io_start() first so the reply is processed instead of being discarded. Tested with a Magic Trackpad USB-C (004c:0324) over Bluetooth on 6.18.37: the reported capacity now matches the device (verified against a raw GET_REPORT of report 0x90) and updates on reconnect. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Signed-off-by: Andrei Fed Signed-off-by: Jiri Kosina

HID: input: read battery capacity from its actual report offset

2026-08-03T18:38:09+00:00

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--battery-144 = 100% (Charging) <- report event path hid--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 Reviewed-by: Alec Hall Signed-off-by: Jiri Kosina

Merge branch 'for-7.2/core' into for-linus

2026-06-16T19:57:57+00:00

HID: Input: Add battery list cleanup with devm action

2026-06-02T08:28:39+00:00

The batteries list (hdev->batteries) is not cleaned up during hidinput_disconnect(), but struct hid_battery entries are allocated with devm_kzalloc. When a driver is unbound (e.g. during devicereprobe), devm frees those entries while their list_head nodesremain dangling in hdev->batteries, which persists across rebinds. Link: https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/ Fixes: 4a58ae85c3f9 ("HID: input: Add support for multiple batteries per device") Signed-off-by: Rafael Passos Acked-by: Lucas Zampieri Signed-off-by: Benjamin Tissoires

hid: Pen battery quirk for Surface Pro 12in

2026-06-01T16:36:22+00:00

The pen setup for this device uses bluetooth for communicating battery levels and status instead of reporting it over i2c. Without this quirk, the device either reports an extra, broken phantom battery, or hangs. Signed-off-by: Harrison Vanderbyl Acked-by: Jiri Kosina Signed-off-by: Benjamin Tissoires

Merge branch 'for-7.1/core-v2' into for-linus

2026-04-16T19:01:18+00:00

- fixed handling of 0-sized reports (Dmitry Torokhov) - convert core code to __free() (Dmitry Torokhov) - support for multiple batteries per HID device (Lucas Zampieri)

Input: add keycodes for contextual AI usages (HUTRR119)

2026-03-29T20:02:11+00:00

HUTRR119 introduces new usages for keys intended to invoke AI agents based on the current context. These are useful with the increasing number of operating systems with integrated Large Language Models Add new key definitions for KEY_ACTION_ON_SELECTION, KEY_CONTEXTUAL_INSERT and KEY_CONTEXTUAL_QUERY Signed-off-by: Akshai Murari Acked-by: Dmitry Torokhov Signed-off-by: Jiri Kosina

HID: input: Add support for multiple batteries per device

2026-03-19T14:52:45+00:00

Add support for HID devices that report multiple batteries, each identified by its report ID. The hid_device->battery pointer is replaced with a batteries list. Batteries are named using the pattern hid-{uniq}-battery-{report_id}. The hid_get_battery() helper returns the first battery in the list for backwards compatibility with single-battery drivers. Signed-off-by: Lucas Zampieri Signed-off-by: Benjamin Tissoires