Linux Input/HID development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: VegetablCat <vegetablecat@foxmail.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH] Input: xpad - add support for Beitong KP series controllers
Date: Sun, 26 Jul 2026 08:10:33 +0000	[thread overview]
Message-ID: <20260726081034.307EB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <tencent_2DEADF4D9ADC33A9420BECBEA70B1A7EFD08@qq.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The HID device ID for the receiver dongle uses an incorrect vendor ID (`0x20dd`), which conflicts with the `0x20bc` vendor ID defined in the USB device table, preventing the driver from binding.
- [Low] Missing Kconfig dependency on `CONFIG_HID` for `CONFIG_JOYSTICK_XPAD` leads to build and linkage failures when HID is disabled or built as a module.
--

--- Patch [1]: [PATCH] Input: xpad - add support for Beitong KP series controllers ---
commit bcec2846a21020976ee3a5901681b58a510bad9a
Author: vegetablecat <vegetablecat@foxmail.com>
Subject: Input: xpad - add support for Beitong KP series controllers

This commit adds support for Beitong KP series controllers by reading the 
XUSB10 descriptor to lock them into XInput mode. It also introduces a 
minimal HID receiver driver for the KP40D receiver dongle to prevent 
hid-generic from interfering.

> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index feb8f368f834e..d33ca181dfe8b 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
[ ... ]
> @@ -332,6 +334,32 @@ static const struct xpad_device {
>  	{ 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 },
>  	{ 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 },
>  	{ 0x1ee9, 0x1590, "ZOTAC Gaming Zone", 0, XTYPE_XBOX360 },
[ ... ]
> +	{ 0x20bc, 0x515b, "BETOP BTP-KP40D Controller (White)", 0, XTYPE_XBOX360, FLAG_READ_XUSB10 },
> +	{ 0x20bc, 0x515c, "BETOP BTP-KP40D Controller (White)", 0, XTYPE_XBOX360, FLAG_READ_XUSB10 },
> +	{ 0x20bc, 0x515d, "BETOP BTP-KP40F Controller (White)", 0, XTYPE_XBOX360, FLAG_READ_XUSB10 },
[ ... ]
> @@ -2312,7 +2357,71 @@ static struct usb_driver xpad_driver = {
[ ... ]
> +static const struct hid_device_id xpad_receiver_devices[] = {
> +	{ HID_USB_DEVICE(0x20dd, 0x515c) },
> +	{ }
> +};

[Severity: High]
Is the vendor ID 0x20dd in the HID device table correct?

The USB device table defines product 0x515c with vendor ID 0x20bc,
but the HID device ID table uses 0x20dd. Since a child HID device inherits
its vendor ID from the underlying USB device, will the HID driver fail to
bind to the dongle if it is looking for 0x20dd instead of 0x20bc?

> +MODULE_DEVICE_TABLE(hid, xpad_receiver_devices);
> +
> +static struct hid_driver xpad_receiver_driver = {
> +	.name = "xpad-kp40d-receiver",
> +	.id_table = xpad_receiver_devices,
> +	.probe = xpad_receiver_probe,
> +	.remove = xpad_receiver_remove,
> +};
> +
> +static int __init xpad_init(void)
> +{
> +	int error;
> +
> +	error = hid_register_driver(&xpad_receiver_driver);

[Severity: Low]
Does this driver now require a dependency on the HID subsystem in Kconfig?

Since xpad_init() now unconditionally calls hid_register_driver(), will
building the kernel with CONFIG_JOYSTICK_XPAD=y and CONFIG_HID=m (or
disabled) cause a linker failure due to undefined HID core symbols?

> +	if (error)
> +		return error;
> +
> +	error = usb_register(&xpad_driver);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_2DEADF4D9ADC33A9420BECBEA70B1A7EFD08@qq.com?part=1

  reply	other threads:[~2026-07-26  8:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26  8:01 [PATCH] Input: xpad - add support for Beitong KP series controllers VegetablCat
2026-07-26  8:10 ` sashiko-bot [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-07-26  8:18 VegetablCat
2026-07-26  8:26 ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260726081034.307EB1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vegetablecat@foxmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox