atar-axis
GameSir T7 Wired Controller Not Working
Hi, I'm confused if xpadneo supports wired USB connections or not. I have a wired GameSir T7 controller that I can not get working with original xpad or xpadneo. I was able to get my authentic Microsoft Xbox Series S|X controller working with xboxneo, but not my offbrand GameSir T7 wired controller. I would really like it to work. Any help would be much appreciated. I'm brand new and I'm not sure if I have to add a quirk or something. I'm basically just plugging it in with the hid_xpadneo module loaded.
USB connection can only be supported if the controller uses the HID protocol. No Xbox controller I know of does that. That that, there's a future milestone to also support USB via a user-space gip2hid daemon as a PoC implementation. No time frame is planned yet for implementation but I'll keep this open and attach it to the project.
I was able to find that xone supports my wired controller, so that's a solution for anyone seeing this. However, I have a new issue now. My authentic Microsoft Xbox Series controller when wirelessly connected via bluetooth used to just work, however after switching over to xpadneo, it's now detected as a Xbox 360 controller. Everything still seems to work except for the screenshot button, but it's a bit unnerving. I tried blacklisting hid-xpadneo and using the normal xpad driver, but my controller is not detected anymore. I'm not sure what it used to use before installing xpadneo? Isn't it supposed to be xpad? I can only get it working with hid-xpadneo now. If you can help me get my controller working without xpadneo that would be great, as before all this, it worked perfectly out of the box. I only installed xpadneo in hope that my wired offbrand GameSir controller would work with it. I really don't need xpadneo anymore. I just want the original functionality. Thanks.
No, xpad isn't a HID driver, it's a GIP driver, and that usually sits in the USB layer only. What you're looking for is hid-generic or hid-microsoft which should work for your device.
That hid-xpadneo shows the controller as Xbox 360 controller is mostly cosmetic. It's relevant for very old games which expected a very specific behavior from the controller, and hid-xpadneo maps all inputs to the 360 layout so such old games could work. These days, most of this is fixed and properly mapped by SDL and Proton, so we can probably lift that cosmetic mapping in the future.
If you're using v0.9 of xpadneo, the screenshot button is mapped to a button outside of the core gamepad device, as that cannot map into the Xbox 360 controller spec. It is exposed as a media control button named KEY_RECORD (or similar) which most applications cannot map (including Steam). With v0.10, the button should map to F12 by default, and we will later make that configurable.
So these are your options:
- Bluetooth controllers usually use the HID protocol which is supported by hid-generic (default fallback driver in the kernel), hid-microsoft (supports most Microsoft devices, includes rumble for some controllers), or hid-xpadneo (we try to support rumble on all controllers, provide a consistent button mapping across all models backward compatible with even old games)
- USB controllers usually use the GIP protocol, and Linux doesn't really have a bus driver for that, but drivers like xpad, xow or xone usually implement that and map it directly to the Linux input layer (I'm working on an idea to convert GIP to HID so such devices can be used by the generic HID drivers)
- Some rare USB controllers also operate in HID mode, this probably affects some or all Playstation controllers, or Nintendo controllers, those are covered by completely different drivers (but some third party controllers support multiple platforms and you can switch between Xbox/Nintendo/Playstation modes), in that case hid-xpadneo could in theory support them and there's an open request to maybe support some Nintendo mode controllers as the Nintendo HID protocol has gyro controls
- Some USB controllers come with a radio dongle but they actually still operate in GIP mode, this is not to be confused with Bluetooth: yes, it's wireless, too, but technically with the special dongles, the kernel doesn't see the radio part, it just sees the USB connection, much like with Bluetooth, the kernel drivers for the controllers don't see the Bluetooth radio part, they just see the HID protocol (xpadneo doesn't see the Bluetooth radio part, it's just a HID driver)
Blacklisting hid-xpadneo thus means that hid-generic or hid-microsoft will take the job again.
On another note: If hid-xpadneo is still installed, blacklisting may not be enough because we have udev rules in place which actively rebind supported devices from hid-generic or hid-microsoft (or any other hid driver) to hid-xpadneo. Blacklisting xpadneo will just result in the rebind to fail, and the device becomes disconnected from the original hid-driver. There should be a file udev/rules.d/60-xpadneo.rules in /etc or /usr/lib which you'd need to disable or shadow. You may also have to shadow or disable the alias list which aliases the controller's Plug and Play IDs to xpadneo (modprobe.d/xpadneo.conf).
This rebinding is needed if xpadneo is built as a loadable module (which is default unless you use my kernel patches outside of this project): Without rebinding, xpadneo won't auto-load because the kernel doesn't yet know that hid-xpadneo is a specialized driver for Xbox HID controllers. You can completely drop the rebinding rule if you force-load xpadneo during boot instead.
This is the udev rule:
ACTION=="bind", \
SUBSYSTEM=="hid", DRIVER!="xpadneo", KERNEL=="0005:045E:*", \
KERNEL=="*:02FD.*|*:02E0.*|*:0B05.*|*:0B13.*|*:0B20.*|*:0B22.*", \
ATTR{driver/unbind}="%k", ATTR{[drivers/hid:xpadneo]bind}="%k"
Essentially it says: If the kernel has bound the controller to any HID driver other than xpadneo, disconnect it again, then connect it to hid-xpadneo instead. This results in the kernel detecting the controller twice once per boot on initial connect - that's mostly a cosmetic issue.