Xbox Controller still shown as connected after disconnecting

[OffApparition]

Version of xpadneo

xpadneo-dkms 0.9.6-1

Controller Model

• Xbox One S controller
• Xbox Elite 2 controller
• Xbox Series X|S controller
• Other:

Connection mode

• Bluetooth connection
• USB cable (not yet supported)
• Xbox Dongle connection (not yet supported)

Installed Software

• Anti-Micro (may affect button mappings)
• OpenRGB (may mess up mappings and rumble stability)
• Steam Input (enabled by default via Steam Desktop client)
• Steam Link (usually via Raspberry Pi or other micro computers)
• devices with QMK firmware (may affect udev rules, similar to OpenRGB)
• netstick (shares input devices via network similar to Steam Link)
• xboxdrv (user-space gamepad driver)
• xone (kernel-space gamepad driver using the Xbox dongle or USB)
• xow (alternative driver using the Xbox dongle)

Protocol Information

Please help us identify at which layer the problem can be found if you want
to report mapping errors or if the controller fails to be detected:

• Steam Proton games are having issues
• Steam Linux-native games are having issues
  • I don't use Steam or did not try
• games running through Lutris, wine and/or Bottles are having issues
  • I don't use Lutris, Bottles, wine or did not try
• Linux-native games are having issues
  • I don't use native games or did not try
• Other software is having issues (describe software and issues below)
• Running evtest is showing issues (describe the issues below)
  • Keep in mind that BTN_NORTH and BTN_WEST are intentionally swapped
• Running jstest is showing issues (describe the issues below)
  • I don't have this tool or don't know how to use it
• Running gamepad-tool is showing issues (post console output below)
  • I don't have this tool

Please describe how it is failing below in the next sections.

Severity / Impact

• I've read the docs and the bug reporting instructions
• I've applied the latest firmware update to the controller
• I've tried disabling or running without above mentioned software
• It does not work at all
• It used to work in a previous version
• It mostly works but sometimes it doesn't
• I found a work-around
• I probably didn't figure it all out but it's too early to give up
• I don't know how to ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the Bug

After disconnecting my Xbox Controller, my system still shows that the controller is connected. Steam will show controller support for my Xbox Controller on game pages (it does not do that when no controller is connected).
Furthermore, I can see the controller under System Settings > Game Controller (on KDE). It shows my Xbox Controller (/dev/input/event22).
When running the following command after disconnecting the controller

# lsmod | grep hid_xpadneo
hid_xpadneo            40960  0
ff_memless             20480  1 hid_xpadneo

I can still see xpadneo even though no controller is connected.

This messes up other controller inputs, e.g. when connecting my PS4 controller after the Xbox controller was disconnected. Input will behave in a weird manner. Buttons will be sent constantly pressed and the input of the other controller will be drowned by constant input being sent from the already disconnected controller.

Steps to Reproduce

1. Connect Xbox Controller
2. Disconnect Xbox Controller
3. Controller is still shown

Expected Behavior

Controller should not be shown anymore.

Screenshots / GIFs / Videos

The controller was not connect to the computer while these screenshots were taken.

Usually in the System Settings there is no entry (when booting the system before connecting the Xbox controller) and Steam does not show any controller support information.

System Information

# uname -a
Linux spectra 6.9.1-zen1-2-zen #1 ZEN SMP PREEMPT_DYNAMIC Wed, 22 May 2024 13:47:12 +0000 x86_64 GNU/Linux

# 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

Controller and Bluetooth Information

Additional Context

[kakra]

This is a new behavior of bluez that it no longer destroys input devices of disconnected endpoints, and reuses the same input device node if the endpoint reconnects. You can disable this behavior in the bluez config.

And yes, it messes up Steam games if you switch controllers because many Windows games often only look at the first controller.

I'm leaving this open so we can document this behavior. I currently can't recall where I found the info about that change, it was in one of the commits to bluez, pointing to a hidden configuration variable you can set.

[czak]

I'm also seeing this behavior.
I tried a few older versions of BlueZ and the new behavior first started in 5.73.
I compared 5.72...5.73 and believe this change boils down to these 3 commits.
I think the virtual_cable_unplug flag matters here, but I don't know how/if it maps to a BlueZ configuration setting.

[kakra]

You could try UserspaceHID=false. It seems this was changed to default to true to actually support the "virtual cable unplug" flag.

[kakra]

There's also this in the changelog:

ver 5.55:
	...
        Fix issue with handling HID virtual cable unplug.
	Fix issue with handling HID channel disconnect order.
        ...

ver 2.8:
        ...
	Add support for HID virtual cable unplug.
        ...

So it seems the feature was already added way earlier but only lately, it has been enabled by default.

[OffApparition]

This issue seems to have been fixed. I can turn off my Xbox controller and it won't show as connected anymore (in Steam and in system settings).
Sadly, another issue came up. When I reconnect my Xbox controller after it has been disconnected previously, I get the controller vibration which confirms the connection but no button input works. I can see the controller in the system settings but none of my button inputs is being sent. A quick fix for me is to just unload and reload the module via

sudo rmmod hid_xpadneo
sudo modprobe hid_xpadneo

The controller will vibrate again and input works like it should.
I'm not sure if this is related to the original issue.

[moll]

I'll just in case mention another oddity I saw a few days ago around the same topic. I've yet to debug this further, but after a reconnect (and a reused input node), sticks, triggers and the D-pad worked, but the ABXY buttons didn't report anything when running evtest. That was with the latest master as of a few days ago. Reloading hid_xpadneo cleared that up.

[kakra]

Can you guys verify that the controller is gone in evtest after you disconnected it? Also, after reconnected, check if another controller appears in evtest and if any of them show button presses.

[OffApparition]

Can you guys verify that the controller is gone in evtest after you disconnected it? Also, after reconnected, check if another controller appears in evtest and if any of them show button presses.

Running evtest after the controller has been disconnected won't show any available devices for me. After reconnecting the controller it'll show up under available devices again. I can also see that the input, at least in evtest, is working properly. All button presses are registered. When going into system settings or any steam game, no input will work though.
I also just saw that initially the controller is recognized as /dev/input/event23 but after disconnecting and reconnecting, it will be shown as /dev/hidraw5 in the system settings. Running evtest however will always show /dev/input/event23 when the controller is connected.

[kakra]

If it shows hidraw, the system settings do not unconditionally use evdev devices. Using hidraw is usually done through SDL. Do your system settings use SDL for controller input?

Our hidraw devices should be unreadable (check permissions of whatever hidraw device shows up: check dmesg to see if it is the same that xpadneo grabbed, then check /dev/hidrawXX that it doesn't have any permissions at all). SDL is currently not compatible with our hidraw device and thus should not use it but use the evdev device instead.

If there are permissions, revoke them (chmod a-rwx /dev/hidrawXX), close system settings, start the app again, see if it works now. If it does, something is overriding our udev permission presets, probably OpenRGB or qmk firmware packages. Whatever software does this: it should not do it. Unconditionally giving world access to input devices is a security risk and bypasses keylogger protection of wayland.

That being said: Future versions of xpadneo will create hidraw devices compatible with SDL. It's scheduled for after release of v0.10.

[OffApparition]

You're right, it was a udev rule aimed at my Keychron keyboard (qmk firmware). Disabling the udev rule solved the problem. I can now disconnect and reconnect my controller without any problems. Thanks a lot!

[kakra]

Yeah, qmk should really fix adjusting permissions only for supported devices. Usually, the desktop has no business in accessing the hidraw devices (you can confirm that by seeing that even evtest cannot access keyboard devices, at least without qmk) because it opens up opportunities for keylogging. qmk probably needs that for programming, that should be offloaded to a daemon that runs with appropriate permissions and only allow the programming access through some API. Simply implementing hidraw access in the desktop client directly is wrong. It is okay for gaming input devices, but not for devices your are going to input passwords or other sensitive information with.