fix(vader5): block only xpad so the pad stays discoverable (#355)#362
Merged
Conversation
padctl self-detaches the kernel HID driver when it libusb-claims IF1/IF2/IF3, so blocking hid_generic/usbhid at udev was redundant — and it removed the hidraw node that padctl's discovery depends on, leaving the daemon with "no devices connected" (regression from #357). Block only xpad: usbhid stays bound so the hidraw node exists for discovery, and the libusb claim still detaches it at runtime and hides the pad from Steam.
Review Summary by QodoFix Vader 5 device discovery by unblocking hid_generic/usbhid
WalkthroughsDescription• Revert excessive kernel driver blocking that broke device discovery • Block only xpad driver, allow hid_generic/usbhid to bind normally • Hidraw node now exists for discovery before libusb claims interfaces • Updated interface documentation to reflect actual behavior Diagramflowchart LR
A["Kernel drivers bind<br/>hid_generic/usbhid"] -->|"hidraw node created"| B["Discovery finds device"]
B -->|"padctl claims IF1/IF2/IF3"| C["libusb detaches kernel driver"]
C -->|"hidraw nodes removed"| D["Steam sees virtual Elite pad"]
E["xpad blocked at udev"] -.->|"prevents double-input"| D
File Changes1. devices/flydigi/vader5.toml
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Flydigi Vader 5 Pro device configuration is updated to block only the ChangesFlydigi Vader 5 device configuration
Possibly related PRs
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Review by QodoSorry, something went wrongWe weren't able to complete the code review on our side. Please try again |
BANANASJIM
added a commit
that referenced
this pull request
Jun 4, 2026
BANANASJIM
pushed a commit
that referenced
this pull request
Jun 6, 2026
…355) - Add generateReprobeRulesFromEntries -> 62-padctl-reprobe.rules: on add|bind of a supported VID:PID, reprobe the interface if it is still driverless (live `test -e /sys%p/driver` check; %p/%k substituted by udevd, matching the 61 driver-block rule). Root-scoped via udevd; coldplug-replayed at boot. - Wired into install after the 61 block rule; added to /lib and /etc cleanup. - Complements the install-time probeAndReprobeDrivers (immediate case). Defense-in-depth safety net only: on current main nothing leaves the interface driverless at boot (the usbhid-in-block_kernel_drivers regression was fixed in PR #362). Kept unmerged until a real-boot capture from an affected machine confirms a genuinely driverless interface.
This was referenced Jun 6, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Revert the
block_kernel_driversexpansion from #357: block onlyxpad, nothid_generic/usbhid. IF1 (vendor) and IF2/IF3 (suppress) are still claimed via libusb.Why
#357 added
hid_generic/usbhidtoblock_kernel_driversso the physical pad's hidraw nodes would vanish. But padctl already callslibusb_detach_kernel_driverbeforelibusb_claim_interface(src/io/usbraw.zig), so it self-detaches the kernel HID driver at claim time — the udev block was redundant.It was also harmful: device discovery is hidraw-only (
HidrawDevice.discoverAllWithRoot). Blockingusbhid/hid_genericat udev means the kernel never creates a hidraw node, so discovery finds nothing and the daemon reports "no devices connected" (#355, reported by two users on Bazzite).With
block = ["xpad"]: usbhid binds -> hidraw node exists -> discovery finds the pad -> the libusb claim detaches usbhid and removes the nodes -> Steam sees only the virtual Elite pad. No reintroduction of the double-input that a full hidraw rollback would cause.Changes
devices/flydigi/vader5.toml:block_kernel_drivers["xpad","hid_generic","usbhid"]->["xpad"]; updated the interface comment. No code change (block_kernel_driversis install-time-only input to udev generation).Test plan
zig build testgreen in the canonical Docker image.padctl status->device=Flydigi Vader 5 Pro state=active.usesLibusb()stays true).Notes
Refs #355, #357
Summary by CodeRabbit