search

atar-axis / xpadneo

Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)
https://atar-axis.github.io/xpadneo/
GNU General Public License v3.0
2.01k stars 113 forks source link

xbox series x controller connected but not working #259

Closed vvdveen closed 2 years ago

vvdveen commented 3 years ago

Version of xpadneo

v0.9-1-g84cabe9

Severity / Impact

Critical

Describe the bug

Connecting the new xbox series x controller fails. Pairing seems successful (the gamepad rumbles), but the X button on the controller continues to blink. Both dmesg and bluetoothctl claim the device is connected. The gamepad is also visible in jspad (there is a /dev/js0), but I am unable to get any interaction with the device.

Disconnecting and reconnecting brings the device in a reconnect loop.

I am on Ubuntu 20.04.1 (LTS). I tried with both my onboard Intel Dual Band Wireless-AC 3168 and a CSR8510 A10 Bluetooth dongle (same results). Today, I updated the controller's firmware to whatever is the latest version. The controller connects perfectly to my Android device.

Steps to Reproduce

See xpadneo-bluetoothctl.txt below. Basically just following the README.

Expected behavior

The device should connect (it seems it does?) and I should be able to use it.

System information

# uname -a
Kernel version: Linux ryzen 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
zsh: no matches found: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor
4294967295 0
# ls /sys/module/hid_xpadneo/drivers/hid:xpadneo/
bind  module  new_id  uevent  unbind
# maybe I missed something?

Controller and Bluetooth information

Additional context

Happy to help debugging this issue further!

dk89 commented 3 years ago

I'd like to attach to this issue because I have the same problem with my Series X Controller and my Raspberry PI 4 (Rasbian buster / RetroPie). Some time it says connected but the X keeps blinking and sometimes it's in a connection loop and keeps trying to connect.

System information

# uname -a
Linux retropie 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)

Controller and Bluetooth information

xpadneo-btmon.txt xpadneo-dmesg.txt

vvdveen commented 3 years ago

Good to see I am not the only one :)

A different machine with an Intel Wireless 7260 chipset gives me similar issues.

I did manage to get the report_descriptor:

➜  0005:045E:0B13.0003 xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0c 15 00 25 01 75 01 95 0c 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 04 81 03 05 0c 0a b2 00 15 00 25 01 95 01 75 01 81  u............%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0f 09 21 85 03 a1 02 09  ...%.u........!.....
000000c8: 97 15 00 25 01 75 04 95 01 91 02 15 00 25 00 75 04 95 01 91  ...%.u.......%.u....
000000dc: 03 09 70 15 00 25 64 75 08 95 04 91 02 09 50 66 01 10 55 0e  ..p..%du......Pf..U.
000000f0: 15 00 26 ff 00 75 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08  ..&..u.........&..u.
00000104: 95 01 91 02 65 00 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91  ....e.U..|..&..u....
00000118: 02 c0 c0                                                     ...
2986910699 1363
kakra commented 3 years ago

This is not an xpadneo issue, apparently. Secretly, I wish it would, then we could do something about it. But I found myself in a similar situation lately. But I was able to get it back to a working state by repeating the following steps until the link key appeared successfully in /var/lib/HOST-MAC/DEVICE-MAC/info using bluetoothctl:

  1. Use remove DEVICE-MAC
  2. Put the controller into pairing mode
  3. Wait for it to announce itself, then use pair DEVICE-MAC
  4. When it paired, immediately run connect DEVICE-MAC
  5. Check if the link key was written to the info file, otherwise restart from step 1
  6. Reboot

I needed to repeat the steps for 5-10 times until the controllers successfully connected again, and after reboot, it would even auto-connect again now without waiting 30-60s. It looks like repeating the steps often enough clears some internal broken state in the controller, or it depends on the timing you're doing the steps at.

Sometimes, it also works using the KDE GUI to pair the device by going through the "new device wizard" instead of using connect to select one from the devices shown. Whatever I did, it was important to remove the device first with bluetoothctl.

vvdveen commented 3 years ago

Thanks! I tried your suggestion many times now, but no link key shows up.

Do you think that the the missing link key is also causing the connect/disconnect loop later? The output of btmon makes me think it might be related (missing PIN or Key missing, so encryption fails, so the device disconnects):

...
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28    #54 [hci1] 4.818729
        Handle: 68
        Random number: 0x6001800500180660
        Encrypted diversifier: 0x001e
        Long term key: 80016006180005800160061800058001
> HCI Event: Command Status (0x0f) plen 4                   #55 [hci1] 4.824574
      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)
> HCI Event: Encryption Change (0x08) plen 4                #56 [hci1] 4.920600
        Status: PIN or Key Missing (0x06)
        Handle: 68
        Encryption: Disabled (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3              #57 [hci1] 4.920637
        Handle: 68
        Reason: Authentication Failure (0x05)
...

What if we get a working link key from when the device is connected to Windows? Would that work? Also, what piece of software do you think is failing here? The bluetoothctl backend? The bluetooth driver? Something else?

kakra commented 3 years ago

Yes, I think it's possible to get the link key from the Windows registry and put it into the Bluetooth info file - but I'm not sure if the format needs to be converted. But I think it's possible according to the very early development stages of this driver. Also, I do not remember where it is stored.

Did you turn off ERTM? Otherwise, it won't work at all because the device disconnects due to invalid configuration profiles requested (which will result in a similar loop).

Another difference may be that I'm using the L2CAP patch instead of disabling ERTM. It's in the misc folder.

kakra commented 3 years ago

Also, there have been firmware updates fixing Bluetooth pairing and connection stability for the older models, maybe check if your model already has an update available. Windows will install firmware updates to the controller only in USB or GIP-dongle mode, not in Bluetooth mode.

albertzdic commented 3 years ago

Connecting the new xbox series x controller fails. Pairing seems successful (the gamepad rumbles), but the X button on the controller continues to blink. Both dmesg and bluetoothctl claim the device is connected.

Same here. I have ERTM disabled. I tried your suggestion several time without success. Thanks for the work on the driver. btmon.txt dmsg.txt lsbus.txt uname.txt

kakra commented 3 years ago

Also, what piece of software do you think is failing here? The bluetoothctl backend? The bluetooth driver? Something else?

I'm not sure what exactly fails here. It's in the Bluetooth stack for sure - but if that's the kernel or the bluez daemon, I'm not sure. If we look at Android which uses the Linux kernel but a different Bluetooth stack (fluoride), and seeing that the controller pairs without problems there, it looks like the problem is in the bluez daemon. OTOH, the controller seems to behave differently based on the Bluetooth stack it sees, and after all seeing that the L2CAP patch works around one of the problems points to the kernel. It may be a bad combination of all three: The kernel, the bluez daemon, and the firmware.

If you manage to pair the controller by transferring the link key from Windows to Linux, it may be interesting to see if the controller presents us a different HID descriptor - and thus may have a "Windows mode".

Maybe we should check if the Linux kernel of Android uses some Bluetooth patches to support its fluoride daemon better. I haven't yet been able to compile fluoride in Linux.

kakra commented 3 years ago

Maybe we should check if the Linux kernel of Android uses some Bluetooth patches to support its fluoride daemon better. I haven't yet been able to compile fluoride in Linux.

Skimming through the commits to net/bluetooth and drivers/bluetooth in the Android kernel didn't reveal any Android-specific patches, so I think they are using the upstream kernel there. So the problem may be in Bluez. If someone manages to compile fluoride for a Linux distribution, it would be interesting to see if it fixes the connection problems, maybe even the rumble-associated disconnects.

albertzdic commented 3 years ago

I tried to compile fluoride but without success, i get error using gn as a build system.

albertzdic commented 3 years ago

Now my controller works. I had to install windows to a virtual machine, start the app xbox accessories and upgrade the firmware, the upgrade was unsuccessful and the app don't recognize the controller in windows vm, but now in linux the controller works on bluetooth and on usb.

I don't now how but it's fixed.

kakra commented 3 years ago

Now my controller works.

What did you do?

albertzdic commented 3 years ago

I upgraded the firmware of the controller with the windows app in a virtual machine. The upgrade was unsuccessful but now in linux bluetooth works.

kakra commented 3 years ago

Yeah, there may a problem with updating in a virtual machine in that the controller reboots into a flash mode, and thus disconnects from the VM. You'd need to immediately re-connect it in that case for the firmware update to be successful.

albertzdic commented 3 years ago

Only a little thing is changed: when the controller is connected by bluetooth the share button is mapped to select (the left button), when is connected by usb the select button is mapped correctly.

albertzdic commented 3 years ago

Yeah, there may a problem with updating in a virtual machine in that the controller reboots into a flash mode, and thus disconnects from the VM. You'd need to immediately re-connect it in that case for the firmware update to be successful.

ooops, i hope everything is ok

kakra commented 3 years ago

ooops, i hope everything is ok

Should be, if no firmware is being sent in that mode, nothing happens and the device will boot back normally after re-plugging it.

when the controller is connected by bluetooth the share button is mapped to select (the left button)

Looks like MS likes to shuffle buttons around again on firmware update. We should inspect that and fix the button, and if we cannot properly detect one or the other firmware, I'd prefer going with what the newer firmware provides.

albertzdic commented 3 years ago

also X and Y are inverted

RustyStriker commented 3 years ago

Also had this problem, booted into my windows 10, updated the controller's firmware, fixed all issues... It seems the xbox sx require the update in order to function properly, as before the update it would connect and dc multiple times(not always rumbling). Axises and buttons didnt change for me

japgolly commented 3 years ago

I booted into Win 10 and updated the firmware too but unfortunately I still can't get mine to work in Linux :(

johnhoran commented 3 years ago

Similiar issue, on first pairing I noticed 

(II) config/udev: Adding input device Xbox Wireless Controller (/dev/input/js0)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device Xbox Wireless Controller (/dev/input/event25)
(**) Xbox Wireless Controller: Applying InputClass "libinput keyboard catchall"
(II) Using input driver 'libinput' for 'Xbox Wireless Controller'
(II) systemd-logind: got fd for /dev/input/event25 13:89 fd 64 paused 0
(**) Xbox Wireless Controller: always reports core events
(**) Option "Device" "/dev/input/event25"
(**) Option "_source" "server/udev"
(II) event25 - Xbox Wireless Controller: is tagged by udev as: Keyboard Joystick
(II) event25 - Xbox Wireless Controller: device is a keyboard
(II) event25 - Xbox Wireless Controller: device removed
(**) Option "config_info" "udev:/sys/devices/virtual/misc/uhid/0005:045E:0B13.0008/input/input29/event25"
(II) XINPUT: Adding extended input device "Xbox Wireless Controller" (type: KEYBOARD, id 18)
(II) event25 - Xbox Wireless Controller: is tagged by udev as: Keyboard Joystick
(II) event25 - Xbox Wireless Controller: device is a keyboard

in journalctl, so I tried adding 0B13 entries to udev and modprobe. My controller now vibrates but the pairing light never stops flashing and it never appears in steam.

kakra commented 3 years ago

when the controller is connected by bluetooth the share button is mapped to select (the left button)

Should be fixed in my queued commits. I was seeing a similar problem for XBE2, and that resulted from an SDL2 upgrade that put the controller into its database.

keidax commented 3 years ago

Having the same issue, I upgraded the firmware in Windows but that didn't make any difference. After applying @kakra's changes to udev and modprobe, I see these two errors in journalctl output:

Nov 29 00:14:36 titan kernel: Bluetooth: hci0: link tx timeout
Nov 29 00:14:38 titan kernel: input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0009/input/input34
Nov 29 00:14:38 titan kernel: hid-generic 0005:045E:0B13.0009: input,hidraw6: BLUETOOTH HID v5.05 Gamepad [Xbox Wireless Controller] on 8c:c6:81:ce:51:d9
Nov 29 00:14:38 titan systemd-udevd[10333]: 0005:045E:0B13.0009: /etc/udev/rules.d/98-xpadneo.rules:3 Failed to write ATTR{/sys/devices/virtual/misc/uhid/0005:045E:0B13.0009/[drivers/hid:xpadneo]bind}, ignoring: No such file or directory
kakra commented 3 years ago

I'd say you are in the reconnect loop then currently. The udev error is there because the device is already gone, our driver wasn't even loaded yet. Do you see the link key in the Bluetooth database?

vvdveen commented 3 years ago

Found some time to look at this again. I extracted the key information from the windows registry and added a LinkKey section to the /var/lib/bluetooth/<mac>/<mac>/info file. Connecting with bluetoothctl didn't work (again a loop). I then removed the configuration files and tried again from bluetoothctl. This time it did work and it seems to be pretty stable also. It is weird, because I tried this many times before with no luck. The only difference now is that I paired the controller in Windows, which maybe removed some internal state in the controller? Or I got lucky...

There is no LinkKey section in the bluetooth info file.

kakra commented 3 years ago

I'm suspecting that there is some internal state that gets cleared by luck sometimes, otherwise I cannot explain the seemingly random behaviors. The link key section shouldn't be missing, tho. You might by lucky to get it when trying to pair again.

ShadowNinja commented 3 years ago

I can confirm that booting into Windows, pairing the controller, and then unpairing it while it's connected fixes the failure to pair.

Steps I followed:

Shatur commented 3 years ago

I had the same problem. Controller worked only via USB. I downloaded the latest version of Windows, updated the controller firmware via Xbox Acessories and paired. Then rebooted into Linux and now it works. But yes, with wrong button mappings. Via USB controller still have correct mappings.

kakra commented 3 years ago

But yes, with wrong button mappings. Via USB controller still have correct mappings.

I have a fix queued. I'll create a PR for it for you to test. I don't have this controller so I cannot test myself but it seems a similar issue like with the Elite 2 controller in SDL.

Shatur commented 3 years ago

I'll create a PR for it for you to test.

Great, just ping me.

keidax commented 3 years ago

I'm not exactly sure what the "link key" looks like. After the controller rumbles but the light is still blinking, I can see these sections in /var/lib/HOST-MAC/DEVICE-MAC/info:

[General]
...
[IdentityResolvingKey]
...
[RemoteSignatureKey]
...
[LocalSignatureKey]
...
[LongTermKey]
...
[SlaveLongTermKey]
...
[DeviceID]
...

Does that look correct, or should there be something else called link?

I tried pairing and unpairing in Windows several times, which didn't seem to make a difference. But I'm using Windows on a separate laptop, not in a dual-boot situation. Maybe it only works once already paired with the same Bluetooth controller device?

kakra commented 3 years ago

The sections are different for BLE... Bluetooth up to Xbox Elite 2 have only one key section.

dk89 commented 3 years ago

My controller works now. First of all I deactivated my internal Bluetoothcontroller an bought an external USB Bluetooth Controller, because the internal had a pretty bad range.

After that I got the same problems like before. But now I connected the controller with my Windows-PC and copied the BLE-paring-keys from the registry to the infofile in Linux. After restarting the Bluetooth service the Controller immediately connected to my Linux.

kakra commented 3 years ago

So one of the failure points seems to be the controller and the Linux Bluetooth stack negotiating the keys properly. It may work in maybe 1 of 20 tries properly but the others just fail. Copying the keys from Windows seems to always work.

keidax commented 3 years ago

After following these instructions, I was able to connect to the controller in Linux.

kolomansell commented 3 years ago

Don't know if it helps somehow but for me worked following:

  1. Install win10 inside VM
  2. plug in BT dongle and add it as USB host device (I am using Asus BT400 dongle - had to install win drivers)
  3. Pair inside Windows.
  4. Turn off windows machine and pair again in linux.
  5. everything works now even after reboot.

No idea... black magic involved probably...

kakra commented 3 years ago

Yeah, it often looks like pairing the controller to any other host which successfully pairs the controller (Android, Windows) usually mostly fixes a following pairing in Linux. I think the Linux Bluetooth stack is incomplete from the view of the Xbox controller firmware and fails to properly initialize. Pairing to a different system may clear some invalid states. I wish it would be possible to somehow firmware-reset the controller, so it starts fresh. But I know of no such reset method.

L0gi commented 3 years ago

After following these instructions, I was able to connect to the controller in Linux.

can confirm that copying keys from windows worked for me as well. At least as far as fixing the pairing and connecting issue (" PIN or Key Missing" Connect/Reconnect loop).

Edit: After connecting controller do other devices had to "e-pair it with a windows pc and recopy the keys... just a heads up for anyone running into the issue.

kolomansell commented 3 years ago

After following these instructions, I was able to connect to the controller in Linux.

can confirm that copying keys from windows worked for me as well. At least as far as fixing the pairing and connecting issue (" PIN or Key Missing" Connect/Reconnect loop).

How is the controller working for you ? Didn't look much into the issue but using mine via bluetooth has a noticable lag. USB connection is flawless.

L0gi commented 3 years ago

After following these instructions, I was able to connect to the controller in Linux.

can confirm that copying keys from windows worked for me as well. At least as far as fixing the pairing and connecting issue (" PIN or Key Missing" Connect/Reconnect loop).

How is the controller working for you ? Didn't look much into the issue but using mine via bluetooth has a noticable lag. USB connection is flawless.

I'm running a osmc rpi3b+ setup trying to get things to work with steamlink (Xbox Wireless controller model 1914 - firmware 5.5.2641.0). Controlling the Kodi UI in osmc seems to be ok. But I'm running into problems with steamlink so couldn't test it in games yet.

The issue with steamlink seems to be that it's for whatever reason doubling over the left analog stick to serve as a super sensitive mouse input. Switching "controller - mouse" (or whatever it's called) in the steamlink overlay doesn't seem to do anything seems to be working as intend - Right analog stick moves a curser at appropriate speeds, left analog stick still spazzes out. But this appears to be a steamlink/osmc issue not related to xpadneo as steamlink does appear to discover the controller as an XInputDevice even with xpadneo removed. Interestingly it doesn't recognize the controller when it's not paired via bluetooth but plugged in through usb directly...

rubencabrera commented 3 years ago

I didn't need to copy the keys from Windows, after it connected on a W10 virtual machine, I could connect to a the host with a 1914 model controller. It's the second gamepad I connect and now none of them shows up for the games I've tested (supertux and a game in steam). Guess that's a different issue, as the connected/disconnected loop that I was experiencing is gone.

kakra commented 3 years ago

@rubencabrera Does it show up in jstest and evtest? If yes, then that's a different issue.

rubencabrera commented 3 years ago

@kakra No, none of the controllers shows up now for those. Nothing is shown in the jstest-gtk, none of the events available in /dev/input/ matches the controllers, the number of options there doesn't change when disconnecting. I can't see changes in /dev/ either.

Funny thing is that on the bluetooth manager they show as connected. While both are, I can see this from bluetoothctl info:

Device 44:16:22:6B:C3:1A (public)
    Name: Xbox Wireless Controller
    Alias: Xbox Wireless Controller
    Appearance: 0x03c4
    Icon: input-gaming
    Paired: yes
    Trusted: yes
    Blocked: no
    Connected: yes
    LegacyPairing: no
    UUID: Vendor specific           (00000001-5f60-4c4f-9c83-a7953298d40d)
    UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
    UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
    UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
    UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
    UUID: Human Interface Device    (00001812-0000-1000-8000-00805f9b34fb)
    Modalias: usb:v045Ep0B13d0501
    ManufacturerData Key: 0x0006
    ManufacturerData Value:
  00

^That's for the 1914 model, if I turn it off, then the info command for the other shows:

Device 44:16:22:0A:D3:B8 (public)
    Name: Xbox Wireless Controller
    Alias: Xbox Wireless Controller
    Class: 0x00000508
    Icon: input-gaming
    Paired: yes
    Trusted: yes
    Blocked: no
    Connected: yes
    LegacyPairing: no
    UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
    UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
    Modalias: usb:v045Ep02FDd0903

Don't want to pollute this issue report with something unrelated, but wasn't sure if it is or not.

kakra commented 3 years ago

So it seems BT is okay. Then maybe the driver is not bound properly. Run dmesg -w in a second terminal and connect the device, watch what happens in the second terminal.

rubencabrera commented 3 years ago

Doing it just for one controller, the model 1708, which used to work fine until the 1914 connected.

[<  549,396284>] hid-generic 0005:045E:02E0.001C: unknown main item tag 0x0
[<    0,000326>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.001C/input/input45
[<    0,000504>] hid-generic 0005:045E:02E0.001C: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93
kakra commented 3 years ago

It doesn't seem to trigger loading/binding xpadneo. Could you check if DKMS actually reinstalled xpadneo after the latest kernel update? I have at least one user report that found DKMS didn't rebuild the driver after kernel update. The cause for this is unknown but you can fix it by reinstalling the driver.

rubencabrera commented 3 years ago

dkms status yields: hid-xpadneo, v0.9-4-gbf8a3c3, 4.15.0-124-generic, x86_64: installed but uname -a shows Linux myhostname 4.15.0-126-generic. I don't remember updating the kernel between the moment the second Xbox controller could connect and when none of the 2 were detected, these 2 events were almost immediate, IIRC. Not sure if there's a correlation here or I just messed with something that made this more confusing.

Well, another kernel update became available, so I just installed.

dkms status showed

hid-xpadneo, v0.9-4-gbf8a3c3, 4.15.0-124-generic, x86_64: installed
hid-xpadneo, v0.9-4-gbf8a3c3, 4.15.0-128-generic, x86_64: installed

but nothing changed.

Uninstalled xpadneo and installed again. When connecting the 1708 controller it rumbled (which it didn't do before even though it was working quite well in every other aspect). The 1914 doesn't rumble but it is now detected and usable in games, there's about half a second lag, but we can leave that for another issue.

I'm going to give it a test run this weekend, thanks a lot for your help!

In case it helps anyone who doesn't have a dual boot or a second windows device (connecting the 1914 controller to an android device didn't do the trick for me):

I used this askubuntu answer as help, what I wrote here adds some of my experience but I found the answer very useful in case you want to check.

kakra commented 3 years ago

If you did the dmesg -w thing again, you should see hid-xpadneo taking over the device this time. I'm not sure if this worked for the second controller: If it doesn't rumble on connect, it's usually not been taken over by xpadneo.

rubencabrera commented 3 years ago

dmesg -w shows when the 1708 connects:

[<   40,686001>] hid-generic 0005:045E:02E0.000B: unknown main item tag 0x0
[<    0,000205>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.000B/input/input28
[<    0,000474>] hid-generic 0005:045E:02E0.000B: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93

1914 controller then enters the connected/disconnected loop as before connecting it to Windows 10 (I'm now stuck at getting the guest VM to see the bluetooth again, for some reason my steps above don't work now -edit: the udev vbox rules had disappeared, I might be touching many things at the same time). No messages are shown in dmesg -w output.

rubencabrera commented 3 years ago

VirtualBox udev rules had disappeared, I reinstalled virtualbox 6.1 and in the Widows 10 VM I had the controller light flashing, so had to remove it and pair it again with Windows 10. That succeeded. I went back to the host and now, again, both controllers connect but xpadneo is not used, I have the same output in dmesg as before. Uninstalling xpadneo and installing again.

Dmesg shows:

First controller (1708):

[<  289,449072>] hid-generic 0005:045E:02E0.0008: unknown main item tag 0x0
[<    0,000202>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.0008/input/input25
[<    0,000549>] hid-generic 0005:045E:02E0.0008: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93
[<    0,095636>] hid_xpadneo: unknown parameter 'disable_ff' ignored
[<    0,000258>] xpadneo 0005:045E:0B13.0006: fixing up Rx axis
[<    0,000004>] xpadneo 0005:045E:0B13.0006: fixing up Ry axis
[<    0,000004>] xpadneo 0005:045E:0B13.0006: fixing up Z axis
[<    0,000004>] xpadneo 0005:045E:0B13.0006: fixing up Rz axis
[<    0,000004>] xpadneo 0005:045E:0B13.0006: fixing up button mapping
[<    0,000491>] xpadneo 0005:045E:0B13.0006: working around wrong SDL2 mappings (changed version from 0x00000501 to 0x00000501)
[<    0,000004>] xpadneo 0005:045E:0B13.0006: enabling compliance with Linux Gamepad Specification
[<    0,000160>] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0006/input/input26
[<    0,000424>] xpadneo 0005:045E:0B13.0006: input,hidraw5: BLUETOOTH HID v5.01 Gamepad [Xbox Wireless Controller] on AC:ED:5C:5D:5E:93
[<    0,000010>] xpadneo 0005:045E:0B13.0006: controller quirks: 0x00000050
[<    0,980188>] xpadneo 0005:045E:0B13.0006: Xbox Wireless Controller [44:16:22:6B:C3:1A] connected
[<    0,000088>] xpadneo 0005:045E:02E0.0008: fixing up report size
[<    0,000211>] xpadneo 0005:045E:02E0.0008: battery detected
[<    0,000002>] xpadneo 0005:045E:02E0.0008: working around wrong SDL2 mappings (changed version from 0x00000903 to 0x00000903)
[<    0,000000>] xpadneo 0005:045E:02E0.0008: enabling compliance with Linux Gamepad Specification
[<    0,000061>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.0008/input/input27
[<    0,000231>] xpadneo 0005:045E:02E0.0008: input,hidraw6: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93
[<    0,000002>] xpadneo 0005:045E:02E0.0008: controller quirks: 0x00000040
[<    0,979578>] xpadneo 0005:045E:02E0.0008: Xbox Wireless Controller [44:16:22:0a:d3:b8] connected
[<    0,798706>] xpadneo 0005:045E:02E0.0008: battery registered

Nothing shows up when I connect the second controller, but what you see in the output above is also related to it (its the MAC ending in 1A).

Both controllers are usable not from games, but 1914 controller is having the half a second lag.

I'll leave things as they are till tomorrow and be sure to not install anything or do any upgrades. I want to see if the same situations repeats itself after a reboot. Let me know if there's any other test of logs that might be useful.