Confirming the same Steam-side symptom on Nobara 44 / kernel 7.2.0-202.nobara.fc44.x86_64, Xbox Elite Series 2 Bluetooth firmware 5.17, with xpadneo v0.11-pre-63-g3acca9f.

After a power cycle, kernel evdev input was present but Steam accepted no controller UI input. hid_xpadneo.ff_connect_notify=0 did not change the result.

The discriminating test was driver/PID handling:

• xpadneo changed the real PID 045e:0b22 to Xbox 360 PID 045e:028e; Steam classified it as a generic Xbox 360 controller.
• Rebinding the same live Bluetooth device to hid-generic restored real PID 045e:0b22; Steam immediately identified Xbox One Elite 2 Controller, enabled SDL_JOYSTICK_HIDAPI_XBOX_ONE, exposed its four paddles, and accepted input without an OS reboot.

This suggests an interaction between Steam/SDL HIDAPI device classification and xpadneo PID spoofing, rather than missing Bluetooth reports. Related xpadneo fix direction: atar-axis/xpadneo#603. I tested the no-spoofing behavior via hid-generic, not that PR branch itself.

Follow-up with a completed two-controller test: a transient form of this problem reproduced even with xpadneo completely absent.

Setup: two identical Elite Series 2 Bluetooth controllers, firmware 5.17, both using hid-generic with real PID 045e:0b22. Steam recognized both correctly, assigned indices/XInput slots 0 and 1, and exposed four paddles on each.

After controller 2 was turned off and back on while controller 1 remained connected, Steam showed both connected but accepted UI input only from controller 1. A second power cycle of controller 2 did not recover it, nor did turning controller 1 off. Recovery required turning both controllers off, then starting controller 2 first. Both worked after controller 1 was started again. Subsequent individual reconnects of either controller succeeded; no Steam restart or OS reboot was required.

Steam logs an invalid/missing hardware unit serial for both and invents synthetic IDs (45e-b22-3ec3d0 / 45e-b22-3ec3d0g). Reconnect logs include Controller device closed after hid_read failure and modify disconnected mapping in-place. Kernel/BlueZ created fresh UHID/HID instances, and Steam reopened the real 045e:0b22 devices. I did not capture raw evdev events during the single failed interval, so that layer remains unproven for this occurrence.

This corrects my earlier report: xpadneo PID spoofing caused a separate, reproducible misclassification and disabling it remains necessary on this system, but it does not eliminate the multi-controller hotplug/device-identity failure completely.

Initial pairing also coincided with a Realtek 0bda:a729 LE scan command timeout (HCI 0x200c, -110) and USB reset. That looks like a separate adapter/scan issue rather than controller capacity.

Final follow-up after a raw reconnect capture. The hotplug failure is nondeterministic: six controlled reconnects succeeded, but the capture exposes a concrete identity problem in Steam.

Setup remained two identical Elite Series 2 Bluetooth controllers (045e:0b22, firmware 5.17), Nobara 44, kernel 7.2.0-202.nobara.fc44.x86_64, BlueZ 5.86. hid_xpadneo was blacklisted and unloaded; both devices used hid-generic throughout.

For each of six cycles, controller 2 was powered off/on while controller 1 stayed connected:

• BlueZ fully removed the old UHID instance before creating the next one; instances advanced from .001C through .0021. No stale/overlapping UHID instance occurred in these successful cycles.
• Raw evdev captures contained input on every new instance. Both controllers also worked in Steam in all six cycles.
• Steam created a new SDL path on every reconnect (sdl://15 through sdl://20) but consistently reopened index 0 / XInput slot 0 and reused synthetic ID 45e-b22-3ec3d0.
• Steam logged serial_number: - 0 / Invalid or missing unit serial number every time.

The important discriminating test is serial discovery: direct SDL_hid_enumerate(045e, 0b22) calls against both the system SDL 3.4.14 and Steam's bundled SDL3 (SDL-release-3.4.0-1163-g2d7f30078) returned both distinct Bluetooth addresses from Linux HID_UNIQ as the serial numbers. InputPlumber also exposed the distinct UniqueId values and had no composite/target devices active. Steam nevertheless discarded or failed to import that identity and generated a synthetic VID/PID-based ID.

This moves the identity loss above BlueZ, hid-generic, InputPlumber, and SDL's Linux hidapi enumeration, into Steam's controller import/identity layer. It also matches ValveSoftware/steam-for-linux#12413, where controller names/slots follow wake order instead of Bluetooth identity, and is relevant to ValveSoftware/Proton#9654.

HCI transport was healthy during this successful capture: all 14 LE Set Scan Enable commands completed successfully in 0.927-11.924 ms; no opcode timeout or USB reset occurred. One LE connection attempt returned 0x3e and the automatic retry succeeded. That is separate from the earlier Realtek 0x200c command timeout/USB reset seen during pairing.

I have the synchronized btmon btsnoop, udevadm monitor --kernel --udev --property, BlueZ D-Bus, kernel, Steam controller log, and per-UHID evdev/hidraw captures. I have not attached the raw btsnoop publicly because it contains Bluetooth addresses, but can provide a sanitized extract or the full capture if a maintainer wants it.