Skip to content

[linux 7.1.y] Add BEITONG KP Series Support - #2025

Open
EvernightFedora wants to merge 1 commit into
deepin-community:linux-7.1.yfrom
EvernightFedora:linux-7.1.y
Open

[linux 7.1.y] Add BEITONG KP Series Support#2025
EvernightFedora wants to merge 1 commit into
deepin-community:linux-7.1.yfrom
EvernightFedora:linux-7.1.y

Conversation

@EvernightFedora

@EvernightFedora EvernightFedora commented Jul 28, 2026

Copy link
Copy Markdown

The BEITONG KP Series Support added latest BTP-KP70C NTE Edition device id.On the Evernight Vista 44.0.1 RTM,the changes can BEITONG KP Series never disconnect and Support NTE Edition Game Controller.

Summary by Sourcery

Add support for additional BEITONG KP-series Xbox-compatible controllers and their wireless receiver to the xpad driver, including required descriptor handling and driver registration changes.

New Features:

  • Recognize multiple new BEITONG BTP-KP series controllers in the xpad USB device table.
  • Introduce optional reading of the Microsoft XUSB10 feature descriptor during probe for selected devices.
  • Add a HID driver for the BEITONG KP40D wireless receiver and integrate its registration alongside the existing USB xpad driver.

Enhancements:

  • Refactor xpad module initialization and teardown to explicitly register and unregister both the USB and HID drivers instead of relying on the generic module_usb_driver macro.

The BEITONG KP Series Support added latest BTP-KP70C NTE Edition
@sourcery-ai

sourcery-ai Bot commented Jul 28, 2026

Copy link
Copy Markdown

Reviewer's Guide

Adds support for multiple BEITONG KP-series Xbox360-compatible controllers, including special handling to read the XUSB10 Microsoft feature descriptor on probe, and introduces a small HID receiver driver plus custom init/exit to register both USB and HID drivers.

Sequence diagram for XUSB10 descriptor read during xpad_probe

sequenceDiagram
    participant USBCore as USB_core
    participant xpad_driver
    participant usb_xpad
    participant usb_device as udev

    USBCore->>xpad_driver: xpad_probe(intf, id)
    xpad_driver->>xpad_driver: allocate usb_xpad
    xpad_driver->>usb_xpad: set read_xusb10 based on FLAG_READ_XUSB10
    xpad_driver->>usb_xpad: usb_submit_urb(xpad->irq_in)
    xpad_driver->>USBCore: usb_set_intfdata(intf, xpad)

    opt [xpad->read_xusb10]
        xpad_driver->>udev: usb_control_msg_recv(0, 0xee, 0x0000, 0x0004, ms_feature_descriptor, sizeof(ms_feature_descriptor), 25)
        alt [error]
            xpad_driver->>USBCore: dev_warn(intf->dev, unable to read Microsoft feature descriptor)
        end
    end

    xpad_driver-->>USBCore: return probe result
Loading

File-Level Changes

Change Details Files
Add BEITONG KP-series device entries with a new flag to read the XUSB10 feature descriptor during probe.
  • Introduce FLAG_READ_XUSB10 and a corresponding read_xusb10 field in the usb_xpad structure.
  • Mark new BEITONG KP-series USB IDs to use the XBOX360 protocol and set the XUSB10-read flag.
  • In xpad_probe, propagate device flags into the usb_xpad instance and, when enabled, issue a vendor-specific usb_control_msg to fetch the Microsoft feature descriptor and log a warning on failure.
drivers/input/joystick/xpad.c
Add a minimal HID driver for a KP40D receiver and switch from module_usb_driver to explicit init/exit to manage both USB and HID drivers.
  • Include <linux/hid.h> and add a HID device table for the xpad receiver VID/PID.
  • Implement simple xpad_receiver_probe/remove that parse, start, open, and close/stop the HID device.
  • Replace module_usb_driver with explicit xpad_init/xpad_exit that conditionally register/unregister the HID driver when CONFIG_HID is reachable, and then register/unregister the USB xpad driver.
drivers/input/joystick/xpad.c

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@deepin-ci-robot

Copy link
Copy Markdown

Hi @EvernightFedora. Thanks for your PR. 😃

@deepin-ci-robot

Copy link
Copy Markdown

Hi @EvernightFedora. Thanks for your PR.

I'm waiting for a deepin-community member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@deepin-ci-robot

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue, and left some high level feedback:

  • Consider adding a short comment near FLAG_READ_XUSB10 / usb_control_msg_recv() explaining why reading the XUSB10 feature descriptor is required for these devices, since the magic request values (0xee, 0x0004, 40 bytes) aren’t otherwise obvious.
  • The optional Microsoft feature descriptor read currently logs a dev_warn() on failure; if this read is purely advisory/quirk-triggering, switching to dev_dbg() or gating the warning behind a one-time message could avoid noisy logs on devices where this is expected to fail.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- Consider adding a short comment near FLAG_READ_XUSB10 / usb_control_msg_recv() explaining why reading the XUSB10 feature descriptor is required for these devices, since the magic request values (0xee, 0x0004, 40 bytes) aren’t otherwise obvious.
- The optional Microsoft feature descriptor read currently logs a dev_warn() on failure; if this read is purely advisory/quirk-triggering, switching to dev_dbg() or gating the warning behind a one-time message could avoid noisy logs on devices where this is expected to fail.

## Individual Comments

### Comment 1
<location path="drivers/input/joystick/xpad.c" line_range="2391" />
<code_context>
+}
+
+static const struct hid_device_id xpad_receiver_devices[] = {
+	{ HID_USB_DEVICE(0x20dd, 0x515c) },
+	{ }
+};
</code_context>
<issue_to_address>
**question (bug_risk):** Double-check the HID receiver VID/PID for consistency with the USB IDs above

The HID receiver entry uses VID 0x20dd / PID 0x515c, but the related BEITONG/BETOP USB xpad entries use VID 0x20bc with 0x515x PIDs. Please verify this VID against the actual receiver descriptor; if it was meant to be 0x20bc, correcting it now will prevent a runtime mismatch where the dongle is not bound correctly.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

}

static const struct hid_device_id xpad_receiver_devices[] = {
{ HID_USB_DEVICE(0x20dd, 0x515c) },

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question (bug_risk): Double-check the HID receiver VID/PID for consistency with the USB IDs above

The HID receiver entry uses VID 0x20dd / PID 0x515c, but the related BEITONG/BETOP USB xpad entries use VID 0x20bc with 0x515x PIDs. Please verify this VID against the actual receiver descriptor; if it was meant to be 0x20bc, correcting it now will prevent a runtime mismatch where the dongle is not bound correctly.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR extends the xpad driver to recognize additional BEITONG KP-series Xbox-compatible controllers, adds a probe-time read of the Microsoft XUSB10 feature descriptor for selected devices, and introduces a small HID driver intended to handle a BEITONG wireless receiver device ID. It also refactors module init/exit to explicitly register both the USB and (optionally) HID drivers.

Changes:

  • Add many new BEITONG KP-series USB IDs to the xpad device table, gated with a new FLAG_READ_XUSB10.
  • During xpad_probe(), optionally issue a vendor control request (0xee) to read the Microsoft feature descriptor for devices marked with FLAG_READ_XUSB10.
  • Add/register a minimal HID driver for a BEITONG receiver and refactor initialization to register/unregister both USB and HID drivers.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +2367 to +2373
error = hid_parse(hdev);
if (error)
return error;

error = hid_hw_start(hdev, 0);
if (error)
return error;
@opsiff

opsiff commented Jul 29, 2026

Copy link
Copy Markdown
Member

请按别的提交的格式修改commit message

@opsiff

opsiff commented Jul 29, 2026

Copy link
Copy Markdown
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants