* Re: [PATCH v4 0/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Vicki Pfau @ 2026-05-12 19:49 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Dmitry Torokhov, Benjamin Tissoires, linux-input
In-Reply-To: <rqposs64-2nnp-5552-nqp3-o45q11328o97@xreary.bet>
On 5/12/26 8:43 AM, Jiri Kosina wrote:
> On Wed, 15 Apr 2026, Vicki Pfau wrote:
>
>> This series adds preliminary support for Switch 2 controllers using the
>> same split-driver model as previous versions. This is a minor iteration on
>> v3 (which was erroneously submitted as v2 again), fixing an issue where we
>> checked for NULL instead of handling an ERR_PTR, as well as a few typo
>> fixes.
>>
>> Vicki Pfau (3):
>> HID: nintendo: Add preliminary Switch 2 controller driver
>> HID: nintendo: Add rumble support for Switch 2 controllers
>> HID: nintendo: Add unified report format support
>
> Vicki,
>
> are you planning v5 with Silvan's comment addressed, please?
Yes, sorry. I was on vacation last week and have had my priorities shifted at work since I got back. I have something else I noticed that needs fixing too. I'll try to get the new version out today.
>
> Thanks,
>
^ permalink raw reply
* [PATCH v2] HID: magicmouse: fix battery reporting for 2024 Magic Trackpad USB-C
From: Dmitri Ollari @ 2026-05-12 19:36 UTC (permalink / raw)
To: linux-input; +Cc: jikos, Dmitri Ollari
In-Reply-To: <20260411163806.35759-1-dmitri.ollari@protonmail.com>
The 2024 Magic Trackpad USB-C (PID 0x0324) does not report battery
strength via HID descriptor fields over Bluetooth. Instead it requires
an explicit HID_REQ_GET_REPORT request to retrieve the battery level.
Replace the battery_timer (timer_list) with battery_work (delayed_work)
so that HID_REQ_GET_REPORT can be issued from a sleepable context.
Timers run in atomic context and cannot block, which caused deadlocks
on the Bluetooth transport path.
Extend the fetch guard and probe scheduling block to include the 2024
Magic Trackpad USB-C when connected over Bluetooth.
Schedule battery_work immediately at probe (delay=0) instead of
issuing a direct magicmouse_fetch_battery() call. The direct call
bypassed the cold-start correction logic and could publish a stale
value before the work handler had a chance to validate it.
Add a cold-start double-poll: the device may return a stale battery
value (e.g. 4%) on the very first GET_REPORT after power-on. On the
first successful poll battery_validated is set and a second poll is
scheduled 3 seconds later to obtain the real value. Subsequent polls
use the normal 60-second interval.
Remove the early-return guard that skipped polling when
battery_capacity equalled battery_max. This prevented the second
corrective poll from firing when the first stale response happened
to equal 100.
Signed-off-by: Dmitri Ollari <dmitri.ollari@protonmail.com>
---
v2:
- Rebased onto v7.1-rc3
- Fixed email line-wrapping and whitespace damage
- Removed PGP signing
drivers/hid/hid-magicmouse.c | 57 ++++++++++++++++++++++--------------
1 file changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index e70bd3dc07ab..1d7c84ecadbb 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -123,7 +123,10 @@ MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state fie
* @tracking_ids: Mapping of current touch input data to @touches.
* @hdev: Pointer to the underlying HID device.
* @work: Workqueue to handle initialization retry for quirky devices.
- * @battery_timer: Timer for obtaining battery level information.
+ * @battery_work: Delayed work for periodic battery level polling.
+ * @battery_validated: Set after the first successful poll; gates the
+ * second poll that corrects the stale value the device may report
+ * on cold start.
*/
struct magicmouse_sc {
struct input_dev *input;
@@ -148,7 +151,8 @@ struct magicmouse_sc {
struct hid_device *hdev;
struct delayed_work work;
- struct timer_list battery_timer;
+ struct delayed_work battery_work;
+ bool battery_validated;
};
static int magicmouse_firm_touch(struct magicmouse_sc *msc)
@@ -822,7 +826,8 @@ static int magicmouse_fetch_battery(struct hid_device *hdev)
bat = hid_get_battery(hdev);
if (!bat ||
(!is_usb_magicmouse2(hdev->vendor, hdev->product) &&
- !is_usb_magictrackpad2(hdev->vendor, hdev->product)))
+ !is_usb_magictrackpad2(hdev->vendor, hdev->product) &&
+ hdev->product != USB_DEVICE_ID_APPLE_MAGICTRACKPAD2_USBC))
return -1;
report_enum = &hdev->report_enum[bat->report_type];
@@ -831,9 +836,6 @@ static int magicmouse_fetch_battery(struct hid_device *hdev)
if (!report || report->maxfield < 1)
return -1;
- if (bat->capacity == bat->max)
- return -1;
-
hid_hw_request(hdev, report, HID_REQ_GET_REPORT);
return 0;
#else
@@ -841,14 +843,25 @@ static int magicmouse_fetch_battery(struct hid_device *hdev)
#endif
}
-static void magicmouse_battery_timer_tick(struct timer_list *t)
+static void magicmouse_battery_work(struct work_struct *work)
{
- struct magicmouse_sc *msc = timer_container_of(msc, t, battery_timer);
+ struct magicmouse_sc *msc = container_of(work, struct magicmouse_sc, battery_work.work);
struct hid_device *hdev = msc->hdev;
if (magicmouse_fetch_battery(hdev) == 0) {
- mod_timer(&msc->battery_timer,
- jiffies + secs_to_jiffies(USB_BATTERY_TIMEOUT_SEC));
+ if (!msc->battery_validated) {
+ /*
+ * The device may return a stale value (e.g. 4%) on the
+ * first GET_REPORT after cold start. Schedule a second
+ * poll shortly after to get the real value, then settle
+ * into the normal 60s interval.
+ */
+ msc->battery_validated = true;
+ schedule_delayed_work(&msc->battery_work, secs_to_jiffies(3));
+ } else {
+ schedule_delayed_work(&msc->battery_work,
+ secs_to_jiffies(USB_BATTERY_TIMEOUT_SEC));
+ }
}
}
@@ -868,6 +881,7 @@ static int magicmouse_probe(struct hid_device *hdev,
msc->scroll_accel = SCROLL_ACCEL_DEFAULT;
msc->hdev = hdev;
INIT_DEFERRABLE_WORK(&msc->work, magicmouse_enable_mt_work);
+ INIT_DELAYED_WORK(&msc->battery_work, magicmouse_battery_work);
msc->quirks = id->driver_data;
hid_set_drvdata(hdev, msc);
@@ -885,11 +899,15 @@ static int magicmouse_probe(struct hid_device *hdev,
}
if (is_usb_magicmouse2(id->vendor, id->product) ||
- is_usb_magictrackpad2(id->vendor, id->product)) {
- timer_setup(&msc->battery_timer, magicmouse_battery_timer_tick, 0);
- mod_timer(&msc->battery_timer,
- jiffies + secs_to_jiffies(USB_BATTERY_TIMEOUT_SEC));
- magicmouse_fetch_battery(hdev);
+ is_usb_magictrackpad2(id->vendor, id->product) ||
+ id->product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2_USBC) {
+ /*
+ * Schedule immediately so battery_work runs ASAP, sets
+ * battery_validated, then reschedules every 60s. Avoids
+ * direct fetch which bypasses battery_validated and would
+ * publish a stale startup value.
+ */
+ schedule_delayed_work(&msc->battery_work, 0);
}
if (is_usb_magicmouse2(id->vendor, id->product) ||
@@ -957,10 +975,7 @@ static int magicmouse_probe(struct hid_device *hdev,
return 0;
err_stop_hw:
- if (is_usb_magicmouse2(id->vendor, id->product) ||
- is_usb_magictrackpad2(id->vendor, id->product))
- timer_delete_sync(&msc->battery_timer);
-
+ cancel_delayed_work_sync(&msc->battery_work);
hid_hw_stop(hdev);
return ret;
}
@@ -971,9 +986,7 @@ static void magicmouse_remove(struct hid_device *hdev)
if (msc) {
cancel_delayed_work_sync(&msc->work);
- if (is_usb_magicmouse2(hdev->vendor, hdev->product) ||
- is_usb_magictrackpad2(hdev->vendor, hdev->product))
- timer_delete_sync(&msc->battery_timer);
+ cancel_delayed_work_sync(&msc->battery_work);
}
hid_hw_stop(hdev);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v1] Input: atlas - Check ACPI_COMPANION() against NULL
From: Dmitry Torokhov @ 2026-05-12 17:57 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-input, LKML, Linux ACPI, Andy Shevchenko
In-Reply-To: <8696590.T7Z3S40VBb@rafael.j.wysocki>
On Tue, May 12, 2026 at 06:26:54PM +0200, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>
> Every platform driver can be forced to match a device that doesn't match
> its list of device IDs because of device_match_driver_override(), so
> platform drivers that rely on the existence of a device's ACPI companion
> object need to verify its presence.
>
> Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
> atlas_btns driver.
>
> Fixes: b8303880b641 ("Input: atlas - convert ACPI driver to a platform one")
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/4] Add MSI Claw HID Configuration Driver
From: Derek John Clark @ 2026-05-12 17:54 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Pierre-Loup A . Griffais, Denis Benato,
Zhouwang Huang, linux-input, linux-doc, linux-kernel
In-Reply-To: <n533qs94-7o4r-p5r0-04p1-68q1398n5785@xreary.bet>
On Tue, May 12, 2026 at 9:13 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Sun, 10 May 2026, Derek J. Clark wrote:
>
> > This series adds and HID Configuration driver for the MSI Claw line of
> > Handheld Gaming PC's. The MSI Claw HID interface provides multiple
> > features, such as the ability to switch between xinput, dinput, and a
> > desktop mode, RGB control, rumble intensity, and mapping of the rear "M"
> > keys. There are additional gamepad modes that are not included in this
> > driver as they appear to be used in assembly line testing or are
> > incomplete in the firmware. During my testing I found them to be unstable.
> >
> > The initial version of this driver was written by Denis Benato, which
> > contained the initial reverse-engineering and implementation for the
> > gamepad mode switching. This work was later expanded by Zhouwang Huang
> > to include more gamepad modes and additional features. Finally, I
> > refactored the entire driver, fixed multiple bugs, and refined the overall
> > format to conform to kernel driver best practices and style guide.
> >
> > Claude was used initially by Zhouwang Huang to quickly parse HID captures
> > during the reverse-engineering of some of the features. Since Claude had
> > already been used, as a test of its capabilities I had it implement the
> > rumble intensity attribute after I had already rewritten most of the
> > driver, which I then manually edited to fix some mistakes. I also used
> > Claude to review the driver and these patches for any mistakes and bugs.
> >
> > Assisted-by: Claude:claude-sonnet-4-6
> > Co-developed-by: Denis Benato <denis.benato@linux.dev>
> > Signed-off-by: Denis Benato <denis.benato@linux.dev>
> > Co-developed-by: Zhouwang Huang <honjow311@gmail.com>
> > Signed-off-by: Zhouwang Huang <honjow311@gmail.com>
> > Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
> >
> > Derek J. Clark (4):
> > HID: hid-msi-claw: Add MSI Claw configuration driver
> > HID: hid-msi-claw: Add M-key mapping attributes
> > HID: hid-msi-claw: Add RGB control interface
> > HID: hid-msi-claw: Add Rumble Intensity Attributes
>
> The driver looks reasonable, I'd just like to propose that we name it just
> hid-msi to follow the usual HID subsystem driver naming standards, so that
> it can later be extended with supporting other MSI devices.
>
Hi Jiri,
Sounds good. I'll do that when I fix the issues flagged by the bot in
v2 and I'll try to have it out some time this week.
Thanks,
Derek
Thanks
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Basavaraj Natikar @ 2026-05-12 17:09 UTC (permalink / raw)
To: Jiri Kosina, Helge Bahmann
Cc: Nehal Bakulchandra Shah, Sandeep Singh, Basavaraj Natikar,
bentiss, linux-hid, linux-input
In-Reply-To: <n0s5q66s-p747-612p-o743-pqr0q2r79448@xreary.bet>
On 5/12/2026 9:36 PM, Jiri Kosina wrote:
> On Mon, 27 Apr 2026, Helge Bahmann wrote:
>
>> Add an input driver that interprets the "operation mode" sensor offered
>> by the amd sfh on some laptop models.
>>
>> Add a quirk to make the driver work again with the Asus VivoBook
>> VivoBook (turn off the "disable interrupts" flag).
>>
>> Expose the intr_disable flag as a module parameter in case it turns out
>> to be needed on further laptop models.
>>
>> Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
> Basavaraj, can you please review this one?
Hi Jiri,
Sure, will review. The patch has some changes that deviate from how
other sensors are exposed in this driver, so it will take some time to
review properly. I'll respond with detailed feedback once done.
Thanks,
--
Basavaraj
^ permalink raw reply
* [PATCH v1] Input: atlas - Check ACPI_COMPANION() against NULL
From: Rafael J. Wysocki @ 2026-05-12 16:26 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, LKML, Linux ACPI, Andy Shevchenko
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
atlas_btns driver.
Fixes: b8303880b641 ("Input: atlas - convert ACPI driver to a platform one")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/input/misc/atlas_btns.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/input/misc/atlas_btns.c
+++ b/drivers/input/misc/atlas_btns.c
@@ -60,11 +60,15 @@ static acpi_status acpi_atlas_button_han
static int atlas_acpi_button_probe(struct platform_device *pdev)
{
- struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
+ struct acpi_device *device;
acpi_status status;
int i;
int err;
+ device = ACPI_COMPANION(&pdev->dev);
+ if (!device)
+ return -ENODEV;
+
input_dev = input_allocate_device();
if (!input_dev) {
pr_err("unable to allocate input device\n");
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for newer Bluetooth keyboards
From: Jiri Kosina @ 2026-05-12 16:16 UTC (permalink / raw)
To: Alain Michaud; +Cc: bentiss, lains, hadess, ogay, linux-input, linux-kernel
In-Reply-To: <20260512132244.2194556-1-alainmichaud@google.com>
On Tue, 12 May 2026, Alain Michaud wrote:
> Add product IDs (PIDs) for several newer Logitech Bluetooth keyboards
> to the hidpp_devices matching table, enabling full HID++ support for
> them.
>
> The added keyboards are:
> - Logitech Signature K650 & B2B
> - Logitech Pebble Keys 2 K380S
> - Logitech Casa Pop-Up Desk & B2B
> - Logitech Wave Keys & B2B
> - Logitech Signature Slim K950 & B2B
> - Logitech MX Keys S & B2B
> - Logitech Keys-To-Go 2
> - Logitech Pop Icon Keys
> - Logitech MX Keys Mini & B2B
> - Logitech Signature Slim Solar+ K980 B2B
> - Logitech Bluetooth Keyboard K250/K251
> - Logitech Signature Comfort K880 & B2B
>
> Signed-off-by: Alain Michaud <alainmichaud@google.com>
> Reviewed-by: Olivier Gay <ogay@logitech.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 5/8] hid: Pen battery quirk for Surface Pro 12in
From: Jiri Kosina @ 2026-05-12 16:15 UTC (permalink / raw)
To: Harrison Vanderbyl
Cc: linux-arm-msm, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <2702fbde567457ea0835ba12cc29421590e688aa.1778498477.git.harrison.vanderbyl@gmail.com>
On Tue, 12 May 2026, Harrison Vanderbyl wrote:
> 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 <harrison.vanderbyl@gmail.com>
As this is apparently part of some bigger series, I am not sure who is
expected to merge this.
FWIW
Acked-by: Jiri Kosina <jkosina@suse.com>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: pidff: Fix integer overflow in pidff_rescale
From: Jiri Kosina @ 2026-05-12 16:13 UTC (permalink / raw)
To: Tomasz Pakuła; +Cc: bentiss, oleg, linux-input, linux-kernel
In-Reply-To: <20260510122352.1161826-1-tomasz.pakula.oficjalny@gmail.com>
On Sun, 10 May 2026, Tomasz Pakuła wrote:
> Rescaling values close to the max (U16_MAX) temporarily creates values
> that exceed the s32 range. This caused value overflow in case when, for
> example, a periodic effect phase was higer than 180 degrees. In turn,
> rescale function could return values outised of the logical range of the
> HID field.
>
> Fix by using 64 bit signed integer to store the value during calculation
> but still return only 32 bit integer.
>
> Closes: https://github.com/JacKeTUs/universal-pidff/issues/116
> Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/4] Add MSI Claw HID Configuration Driver
From: Jiri Kosina @ 2026-05-12 16:13 UTC (permalink / raw)
To: Derek J. Clark
Cc: Benjamin Tissoires, Pierre-Loup A . Griffais, Denis Benato,
Zhouwang Huang, linux-input, linux-doc, linux-kernel
In-Reply-To: <20260510043510.442807-1-derekjohn.clark@gmail.com>
On Sun, 10 May 2026, Derek J. Clark wrote:
> This series adds and HID Configuration driver for the MSI Claw line of
> Handheld Gaming PC's. The MSI Claw HID interface provides multiple
> features, such as the ability to switch between xinput, dinput, and a
> desktop mode, RGB control, rumble intensity, and mapping of the rear "M"
> keys. There are additional gamepad modes that are not included in this
> driver as they appear to be used in assembly line testing or are
> incomplete in the firmware. During my testing I found them to be unstable.
>
> The initial version of this driver was written by Denis Benato, which
> contained the initial reverse-engineering and implementation for the
> gamepad mode switching. This work was later expanded by Zhouwang Huang
> to include more gamepad modes and additional features. Finally, I
> refactored the entire driver, fixed multiple bugs, and refined the overall
> format to conform to kernel driver best practices and style guide.
>
> Claude was used initially by Zhouwang Huang to quickly parse HID captures
> during the reverse-engineering of some of the features. Since Claude had
> already been used, as a test of its capabilities I had it implement the
> rumble intensity attribute after I had already rewritten most of the
> driver, which I then manually edited to fix some mistakes. I also used
> Claude to review the driver and these patches for any mistakes and bugs.
>
> Assisted-by: Claude:claude-sonnet-4-6
> Co-developed-by: Denis Benato <denis.benato@linux.dev>
> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> Co-developed-by: Zhouwang Huang <honjow311@gmail.com>
> Signed-off-by: Zhouwang Huang <honjow311@gmail.com>
> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
>
> Derek J. Clark (4):
> HID: hid-msi-claw: Add MSI Claw configuration driver
> HID: hid-msi-claw: Add M-key mapping attributes
> HID: hid-msi-claw: Add RGB control interface
> HID: hid-msi-claw: Add Rumble Intensity Attributes
The driver looks reasonable, I'd just like to propose that we name it just
hid-msi to follow the usual HID subsystem driver naming standards, so that
it can later be extended with supporting other MSI devices.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: add reset quirk for BLTP7853 touchpad
From: Jiri Kosina @ 2026-05-12 16:11 UTC (permalink / raw)
To: Xu Rao; +Cc: bentiss, linux-input, linux-kernel
In-Reply-To: <882C8FD17740299C+20260509082132.2188313-1-raoxu@uniontech.com>
On Sat, 9 May 2026, Xu Rao wrote:
> The BLTP7853 I2C HID touchpad may fail to probe after reboot or
> reprobe because reset completion is not signalled to the host. The
> driver then waits for the reset-complete interrupt until it times out
> and the device probe fails:
>
> i2c_hid i2c-BLTP7853:00: failed to reset device.
> i2c_hid i2c-BLTP7853:00: can't add hid device: -61
> i2c_hid: probe of i2c-BLTP7853:00 failed with error -61
>
> Add I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for the device so i2c-hid does
> not wait for a reset interrupt that may never arrive.
>
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
Applied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH RESEND 2] HID: Add force feedback support for Speedlink Cougar Vibration Flightstick
From: Jiri Kosina @ 2026-05-12 16:11 UTC (permalink / raw)
To: Harald Judt; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <b3bfa73b-0547-45f9-b6ae-f28815e6c632@gmx.at>
On Fri, 8 May 2026, Harald Judt wrote:
> Hi,
>
> I have implemented force feedback/rumble support for the Speedlink
> Cougar Vibration Flightstick joystick. While I am not quite sure about
> the correctness of my approach regarding the strong and weak motors, it
> seems to work as expected; I ran the fftest samples and also tested it
> successfully with SuperTuxKart.
>
> Here is the code, hopefully I have set up thunderbird mail correctly to
> not mangle the patch...
>
>
> From 48d8512fbe49ae7b940dc5869fe50aa905d3d5fb Mon Sep 17 00:00:00 2001
> From: Harald Judt <h.judt@gmx.at>
> Date: Sun, 18 Jan 2026 02:47:20 +0100
> Subject: [PATCH] HID: Add force feedback support for Gembird based joystick
>
> This commit adds force feedback support for a Gembird based joystick, namely
> the SpeedLink Cougar Vibration Flightstick (SL-6630), which sports vibration
> motors for rumble effects. Though it is not easy to determine, it seems to have
> one motor in the base and the other in the stick, both are of equal
> strength. The implementation tries to take this into account for realising weak
> and strong rumble effects and has been tested using fftest and SuperTuxKart.
>
> Signed-off-by: Harald Judt <h.judt@gmx.at>
> ---
> drivers/hid/Kconfig | 8 ++
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-gembird-joy.c | 178 ++++++++++++++++++++++++++++++++++
> drivers/hid/hid-ids.h | 3 +
> drivers/hid/hid-quirks.c | 3 +
> 5 files changed, 193 insertions(+)
> create mode 100644 drivers/hid/hid-gembird-joy.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 04420a713be0..b4e2c8f67728 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -406,6 +406,14 @@ config HID_GEMBIRD
> help
> Support for Gembird JPD-DualForce 2.
>
> +config HID_GEMBIRD_JOY_FF
> + tristate "Gembird Joysticks force feedback support"
> + depends on USB_HID
> + select INPUT_FF_MEMLESS
> + help
> + Force feedback support for Gembird (Vendor ID 0x12bd) based devices:
> + - Speed Link Cougar Vibration Flightstick (SL-6630)
> +
> config HID_GFRM
> tristate "Google Fiber TV Box remote control support"
> help
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 361a7daedeb8..593a429661ed 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_HID_EVISION) += hid-evision.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> obj-$(CONFIG_HID_FT260) += hid-ft260.o
> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> +obj-$(CONFIG_HID_GEMBIRD_JOY_FF) += hid-gembird-joy.o
Would it be possible to link this support to hid-gembird if enabled?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: pxrc: fix slab-out-of-bounds read/write in pxrc_raw_event()
From: Jiri Kosina @ 2026-05-12 16:10 UTC (permalink / raw)
To: Jinmo Yang
Cc: marcus.folkesson, benjamin.tissoires, linux-input, linux-kernel,
stable
In-Reply-To: <20260508133311.3995013-1-jinmo44.yang@gmail.com>
On Fri, 8 May 2026, Jinmo Yang wrote:
> pxrc_raw_event() accesses data[7] without verifying that the buffer is
> large enough. A device that sends a report shorter than 8 bytes causes
> an out-of-bounds read (priv->dial = data[7]) and an out-of-bounds write
> (data[7] = priv->dial) on the report buffer, corrupting adjacent slab
> memory.
>
> This can be triggered from userspace via /dev/uhid by creating a virtual
> device with VID 0x1781 / PID 0x0898 and sending a short UHID_INPUT2
> report.
>
> Add a size check at the top of pxrc_raw_event() to bail out when the
> report buffer is shorter than 8 bytes.
>
> Fixes: a2dccedac664 ("HID: pxrc: new driver for PhoenixRC Flight Controller Adapter")
Where is this tag coming from?
No such hash exists in Linus' tree, and the commit that actually added the
driver has a different shortlog.
Is this some LLM halucination?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Jiri Kosina @ 2026-05-12 16:06 UTC (permalink / raw)
To: Helge Bahmann
Cc: Nehal Bakulchandra Shah, Sandeep Singh, Basavaraj Natikar,
bentiss, linux-hid, linux-input
In-Reply-To: <6879487.lOV4Wx5bFT@lothlorien>
On Mon, 27 Apr 2026, Helge Bahmann wrote:
> Add an input driver that interprets the "operation mode" sensor offered
> by the amd sfh on some laptop models.
>
> Add a quirk to make the driver work again with the Asus VivoBook
> VivoBook (turn off the "disable interrupts" flag).
>
> Expose the intr_disable flag as a module parameter in case it turns out
> to be needed on further laptop models.
>
> Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
Basavaraj, can you please review this one?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Jiri Kosina @ 2026-05-12 16:04 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Filipe Laíns, Bastien Nocera, Ping Cheng, Jason Gerecke,
Viresh Kumar, Johan Hovold, Alex Elder, Greg Kroah-Hartman,
Lee Jones, Icenowy Zheng, linux-input, linux-kernel, greybus-dev,
linux-staging, linux-usb, stable
In-Reply-To: <20260504-wip-fix-core-v3-0-ce1f11f4968f@kernel.org>
On Mon, 4 May 2026, Benjamin Tissoires wrote:
> Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()") enforced the provided data to be at least the size of
> the declared buffer in the report descriptor to prevent a buffer
> overflow.
>
> We only had corner cases of malicious devices exposing the OOM because
> in most cases, the buffer provided by the transport layer needs to be
> allocated at probe time and is large enough to handle all the possible
> reports.
>
> However, the patch from above, which enforces the spec a little bit more
> introduced both regressions for devices not following the spec (not
> necesserally malicious), but also a stream of errors for those devices.
>
> Let's revert to the old behavior by giving more information to HID core
> to be able to decide whether it can or not memset the rest of the buffer
> to 0 and continue the processing.
>
> Note that the first commit makes an API change, but the callers are
> relatively limited, so it should be fine on its own. The second patch
> can't really make the same kind of API change because we have too many
> callers in various subsystems. We can switch them one by one to the safe
> approach when needed.
>
> The last 2 patches are small cleanups I initially put together with the
> 2 first patches, but they can be applied on their own and don't need to
> be pulled in stable like the first 2.
>
> Cheers,
> Benjamin
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
I have now queued the first two in hid.git#for-7.1/upstream-fixes.
I expect the remaining two will be applied once respun with Dmitry's
suggestion on proper guarding.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: google: hammer: stop hardware on devres action failure
From: Jiri Kosina @ 2026-05-12 16:01 UTC (permalink / raw)
To: 박명훈; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260424125043.52639-1-pakmyeonghun@bagmyeonghun-ui-MacBookPro.local>
On Fri, 24 Apr 2026, 박명훈 wrote:
> From: Myeonghun Pak <mhun512@gmail.com>
>
> hammer_probe() starts the HID hardware before registering the devres
> action that stops it. If devm_add_action() fails, probe returns an
> error with the hardware still started because the cleanup action was
> never registered and the driver's remove callback is not called after a
> failed probe.
>
> Use devm_add_action_or_reset() so the stop action runs immediately on
> registration failure while preserving the existing devres-managed cleanup
> path for later probe failures and remove.
>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> drivers/hid/hid-google-hammer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> index 1af477e584..c99c3c0d44 100644
> --- a/drivers/hid/hid-google-hammer.c
> +++ b/drivers/hid/hid-google-hammer.c
> @@ -496,7 +496,7 @@ static int hammer_probe(struct hid_device *hdev,
> if (error)
> return error;
>
> - error = devm_add_action(&hdev->dev, hammer_stop, hdev);
> + error = devm_add_action_or_reset(&hdev->dev, hammer_stop, hdev);
Makes sense, thanks for catching it. Applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/2] HID: appletb-kbd: fix UAF and mutex-in-atomic in inactivity timer
From: Jiri Kosina @ 2026-05-12 15:57 UTC (permalink / raw)
To: Sangyun Kim; +Cc: bentiss, qasdev00, gargaditya08, linux-input, linux-kernel
In-Reply-To: <20260420051318.1411671-1-sangyun.kim@snu.ac.kr>
On Mon, 20 Apr 2026, Sangyun Kim wrote:
> This series addresses two defects in hid-appletb-kbd's inactivity
> timer subsystem. The two patches target different bugs and are
> logically independent; they are sent together because they touch the
> same tear-down code and because the same maintainer will review both.
>
> Patch 1 fixes a slab use-after-free with two related tear-down windows
> introduced by commit 38224c472a03 ("HID: appletb-kbd: fix slab
> use-after-free bug in appletb_kbd_probe"):
>
> A) Within "if (kbd->backlight_dev)" the order was
> put_device() then timer_delete_sync(). A concurrent
> hid_appletb_bl unbind between those two calls can drop the last
> devm reference and free the backlight_device; the still-armed
> inactivity timer softirq then dereferences the freed object
> through backlight_device_set_brightness() -> mutex_lock(&ops_lock).
>
> B) The "if (kbd->backlight_dev)" block ran before
> hid_hw_close()/hid_hw_stop(), so even after window A is closed a
> late ".event" callback from the HID core (USB URB completion on
> real hardware) can arrive between timer_delete_sync() and
> put_device(), reach reset_inactivity_timer(), re-arm the timer
> via mod_timer(), and reopen the same UAF.
>
> Both windows produce the same KASAN slab-use-after-free on the object
> allocated by devm_backlight_device_register(). Patch 1 closes them
> together by moving hid_hw_close()/hid_hw_stop() before the backlight
> cleanup and, inside that cleanup block, calling timer_delete_sync()
> before put_device(). Shipping both as one commit avoids leaving
> stable kernels in a half-fixed state where only window A is closed.
>
> Patch 2 fixes a separate "sleeping function called from invalid
> context" bug in the same subsystem. The inactivity timer is a
> struct timer_list, so the callback runs in softirq context and calls
> backlight_device_set_brightness() -> mutex_lock() from atomic
> context; reset_inactivity_timer() has the same issue on the
> brightness-restore path (it is called from appletb_kbd_hid_event()
> and appletb_kbd_inp_event(), which run in softirq/IRQ context on
> real USB hardware). Convert the inactivity timer to a delayed_work
> and defer the brightness-restore call to a dedicated work_struct so
> both sleeping calls run in process context.
>
> Sangyun Kim (2):
> HID: appletb-kbd: fix UAF in inactivity-timer cleanup path
> HID: appletb-kbd: run inactivity autodim from workqueues
Both applied to hid.git#for-7.1/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/5] Add OneXPlayer Configuration HID Driver
From: Jiri Kosina @ 2026-05-12 15:56 UTC (permalink / raw)
To: Derek J. Clark
Cc: Benjamin Tissoires, Pierre-Loup A . Griffais, Lambert Fan,
Zhouwang Huang, linux-input, linux-doc, linux-kernel
In-Reply-To: <20260419042624.625746-1-derekjohn.clark@gmail.com>
On Sat, 18 Apr 2026, Derek J. Clark wrote:
> Adds an HID driver for OneXPlayer HID configuration devices. There are
> currently 2 generations of OneXPlayer HID protocol. The first (OneXPlayer
> F1 series) only provides an RGB control interface over HID. The Second
> (X1 mini series, G1 series, AOKZOE A1X) also includes a hardware level
> button mapping interface, vibration intensity settings, and the ability
> to switch output between xinput and a debug mode that can be used to debug
> the button mapping. Some devices (G1 Series, APEX) use a hybrid of Gen1
> RGB control and Gen 2 controller settings. To ensure there is no conflicts
> when the driver is loaded, we skip creating the RGB interface for Gen 2
> devices if there is a DMI match.
>
> I'll also add a note that Gen 1 devices also have an interface for
> setting the key map and debug mode, but that is done entirely over a
> serial TTY device so it is not able to be added to this driver. There
> are also some "Gen 0" devices (OneXPlayer 2 Series) also use it, but
> the TTY interface also handles the RGB control so no support is
> provided by this driver for those interfaces.
>
> Signed-off-by: Derel J. Clark <derekjohn.clark@gmail.com>
> ---
> v4:
> - Make all delayed work part of drvdata & ensure they are canceled
> during remove.
>
> v3: https://lore.kernel.org/linux-input/20260412213444.2231505-1-derekjohn.clark@gmail.com/
> - Ensure default button map is properly init during probe.
>
> v2: https://lore.kernel.org/linux-input/20260407041354.2283201-1-derekjohn.clark@gmail.com/
> - Add DMI quirks for certain devices that ship with both GEN1 and GEN2
> MCU to avoid clashing when initializing the RGB interface.
> - Add left & right vibration intensity attributes.
> - Add additional mappings for keyboard inputs.
> - Add a delayed work trigger to re-apply settings after the MCU
> completes initializing after a suspend/resume cycle.
>
> v1: https://lore.kernel.org/linux-input/20260322031615.1524307-1-derekjohn.clark@gmail.com/
Now in hid.git#for-7.2/oxp, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: playstation: Clamp num_touch_reports
From: Jiri Kosina @ 2026-05-12 15:55 UTC (permalink / raw)
To: T.J. Mercier
Cc: roderick.colenbrander, linux-input, Benjamin Tissoires, stable,
Xingyu Jin, Roderick Colenbrander, linux-kernel
In-Reply-To: <20260417154704.1186803-1-tjmercier@google.com>
On Fri, 17 Apr 2026, T.J. Mercier wrote:
> A device would never lie about the number of touch reports would it?
>
> If it does the loop in dualshock4_parse_report will read off the end of
> the touch_reports array, up to about 2 KiB for the maximum number of 256
> loop iteraions. The data that is read is emitted via evdev if the
> DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by
> clamping the num_touch_reports value provided by the device to the
> maximum size of the touch_reports array.
>
> Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.")
> Cc: stable@vger.kernel.org
> Reported-by: Xingyu Jin <xingyuj@google.com>
> Signed-off-by: T.J. Mercier <tjmercier@google.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6] HID: magicmouse: add battery reporting for Magic Trackpad v1
From: Jiri Kosina @ 2026-05-12 15:53 UTC (permalink / raw)
To: Damiano Gragnaniello; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20260416143323.418078-1-damianogragnaniello@gmail.com>
On Thu, 16 Apr 2026, Damiano Gragnaniello wrote:
[ ... snip ... ]
>
> - /* If there is only one "firm" touch, set touch to its
> - * tracking ID.
> - */
[ ... snip ... ]
> - /* If some button was pressed before, keep it held
> - * down. Otherwise, if there's exactly one firm
> - * touch, use that to override the mouse's guess.
> - */
[ ... snip ... ]
> - /* If requested, emulate a scroll wheel by detecting small
> - * vertical touch motions.
> - */
> - if (emulate_scroll_wheel && (input->id.product !=
> - USB_DEVICE_ID_APPLE_MAGICTRACKPAD2)) {
[ ... snip ... ]
> - /* Reset acceleration after half a second. */
[ ... snip ... ]
> - /* Generate the input events for this touch. */
[ ... snip ... ]
> - /* Expect four bytes of prefix, and N*9 bytes of touch data. */
[ ... snip ... ]
> - /* The following bits provide a device specific timestamp. They
> - * are unused here.
> - *
> - * ts = data[1] >> 6 | data[2] << 2 | data[3] << 10;
> - */
[ ... snip ... ]
> - /* Expect twelve bytes of prefix and N*9 bytes of touch data. */
[ ... snip ... ]
Why are you removing all those comments? (and quite some more).
I don't think your patch changes any of this.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/1] HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID
From: Jiri Kosina @ 2026-05-12 15:49 UTC (permalink / raw)
To: Lee Jones; +Cc: Benjamin Tissoires, linux-input, linux-kernel, gnoack
In-Reply-To: <20260416131655.2279756-1-lee@kernel.org>
On Thu, 16 Apr 2026, Lee Jones wrote:
> It is currently possible for a malicious or misconfigured USB device to
> cause an out-of-bounds (OOB) read when submitting reports using
> DOUBLE_REPORT_ID by specifying a large report length and providing a
> smaller one.
>
> Let's prevent that by comparing the specified report length with the
> actual size of the data read in from userspace. If the actual data
> length ends up being smaller than specified, we'll politely warn the
> user and prevent any further processing.
>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> v1 => v2: Add more size checks to protect against issues during recursion
Applied, sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: fix OOB write in mcp2221_raw_event()
From: Jiri Kosina @ 2026-05-12 15:48 UTC (permalink / raw)
To: Florian Pradines; +Cc: gupt21, bentiss, linux-i2c, linux-input
In-Reply-To: <20260509094517.2691246-1-florian.pradines@gmail.com>
On Sat, 9 May 2026, Florian Pradines wrote:
> mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at
> offset rxbuf_idx without checking that the copy fits within the
> destination buffer. A device responding with up to 60 bytes to a
> small I2C/SMBus read can overflow the buffer.
>
> Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in
> mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size
> before the memcpy.
>
> Signed-off-by: Florian Pradines <florian.pradines@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: Fix heap buffer overflow in mcp2221_raw_event()
From: Jiri Kosina @ 2026-05-12 15:47 UTC (permalink / raw)
To: Benoit Sevens
Cc: Rishi Gupta, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel
In-Reply-To: <20260415114752.1181079-1-bsevens@google.com>
On Wed, 15 Apr 2026, Benoit Sevens wrote:
> From: Benoît Sevens <bsevens@google.com>
>
> A heap buffer overflow can occur in the mcp2221_raw_event() function
> when handling I2C read responses. The driver failed to check if the
> total incoming data length fits within the originally allocated buffer
> `mcp->rxbuf`.
>
> Fix this by introducing `rxbuf_len` to `struct mcp2221` to keep track
> of the allocated buffer size. Initialize it in `mcp_i2c_smbus_read()`
> and `mcp_smbus_xfer()`, and ensure the copied data length combined with
> the current index does not exceed this length in `mcp2221_raw_event()`.
>
> Signed-off-by: Benoît Sevens <bsevens@google.com>
Unfortunately the patch seems to have been somehow mangled by your mail
client:
patching file drivers/hid/hid-mcp2221.c
Hunk #1 succeeded at 126 (offset 7 lines).
Hunk #2 FAILED at 324.
patch: **** malformed patch at line 173: u16 addr,
Fix for the same issue has later been submitted by Florian Pradines [1],
so I will be taking that one and adding you as Reported-by: or so, ok?
Thanks.
[1] https://lore.kernel.org/all/20260509094517.2691246-1-florian.pradines@gmail.com/
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Jiri Kosina @ 2026-05-12 15:43 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Dmitry Torokhov, Benjamin Tissoires, linux-input
In-Reply-To: <20260415073142.1303505-1-vi@endrift.com>
On Wed, 15 Apr 2026, Vicki Pfau wrote:
> This series adds preliminary support for Switch 2 controllers using the
> same split-driver model as previous versions. This is a minor iteration on
> v3 (which was erroneously submitted as v2 again), fixing an issue where we
> checked for NULL instead of handling an ERR_PTR, as well as a few typo
> fixes.
>
> Vicki Pfau (3):
> HID: nintendo: Add preliminary Switch 2 controller driver
> HID: nintendo: Add rumble support for Switch 2 controllers
> HID: nintendo: Add unified report format support
Vicki,
are you planning v5 with Silvan's comment addressed, please?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification
From: Jiri Kosina @ 2026-05-12 15:39 UTC (permalink / raw)
To: Dave Carey; +Cc: linux-input, bentiss
In-Reply-To: <20260413125803.46792-1-carvsdriver@gmail.com>
On Mon, 13 Apr 2026, Dave Carey wrote:
> The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a
> HID_DG_TOUCHPAD application collection designed for the Windows inbox HID
> driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN
> collections provide the correct direct-touch interface. The presence of
> the touchpad collection causes hid-multitouch to misclassify the
> touchscreen nodes as indirect buttonpads, leaving them non-functional.
>
> Within the touchpad collection:
> - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic
> that sets INPUT_MT_POINTER on the touchscreen applications.
> - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via
> mt_allocate_application(), propagating to all touchscreen nodes.
> - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD,
> setting td->is_buttonpad = true for the entire device.
>
> Additionally, the firmware resets if any USB control request arrives while
> the CDC-ACM interface is initialising (~1.18 s after enumeration).
> The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature
> reports in the touchscreen collections trigger GET_REPORT calls at probe
> that hit this window. Surface Switch (0x57) and Button Switch (0x58)
> feature reports are sent by mt_set_modes() on every input-device open and
> close, repeatedly hitting this window throughout device lifetime.
>
> The firmware also leaves a persistent ghost contact in its contact buffer
> (contact ID 2, fixed coordinates, tip always asserted) on every enumeration.
> This ghost occupies a multitouch slot and prevents KWin from seeing a clean
> finger-lift, causing stuck touch state. The ghost is cleared when Input
> Mode is set via HID_REQ_SET_REPORT at probe.
Oh man, what a device.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox