[Bug] Razer Wolverine V2 causes "possible deadlock" error

[Switch123456789]

If this controller is connected:

Razer Wolverine V2
1532:0a29

And any of these files in /usr/share/inputplumber/devices are present at the same time:

60-8bit_do_pro_2.yaml
60-flydigi_vader_4_pro.yaml
60-horipad_steam.yaml
60-LogitechDualAction.yaml
60-ps4_gamepad.yaml
60-xbox_one_bt_gamepad.yaml

Running inputplumber devices manage-all --enable will cause the follow errors:

21:24:10Z INFO  inputplumber::input::manager] Started hidraw device discovery thread
21:24:10Z INFO  inputplumber::input::manager] Started evdev device discovery thread
21:24:11Z INFO  inputplumber::input::manager] Found a matching input device evdev://event11 in config "/usr/share/inputplumber/devices/60-xbox_one_gamepad.yaml", creating CompositeDevice
21:24:11Z INFO  inputplumber::input::manager] Found matching source device for config "/usr/share/inputplumber/devices/60-xbox_one_gamepad.yaml"
21:24:11Z INFO  inputplumber::input::composite_device] Creating CompositeDevice with config: Microsoft X-Box One pad
21:24:11Z INFO  inputplumber::input::composite_device] Loading device profile `Default` from: /usr/share/inputplumber/profiles/default.yaml
21:24:11Z INFO  inputplumber::input::composite_device::targets] [/org/shadowblip/InputPlumber/CompositeDevice0] Setting target devices: [TargetDeviceTypeId { id: "xbox-series", name: "Microsoft Xbox Series S|X Controller", device_class: Gamepad }, TargetDeviceTypeId { id: "mouse", name: "InputPlumber Mouse", device_class: Mouse }, TargetDeviceTypeId { id: "keyboard", name: "InputPlumber Keyboard", device_class: Keyboard }]
21:24:16Z ERROR inputplumber::input::composite_device::client] POSSIBLE DEADLOCK: timed out after 5s waiting for response from composite device
21:24:16Z ERROR inputplumber::input::composite_device::client] POSSIBLE DEADLOCK: timed out after 5s waiting for response from composite device

If I remove exactly the mentioned files, things work fine. I don't have any other controllers connected.

I tried InputPlumber for the first time today and the documentation is barely existing, so please excuse me if this is expected behavior and the user (me) is the problem. Let me know if you need more information or access to my controller/system in case it indeed is a bug.

[dripsnek]

This looks like what was reported in #581 considering all those files you mention have a udev section, though I don't have a modern Xbox controller to test with.

[Switch123456789]

Can I help out? If my controller fits the category "modern xbox controller", maybe I could do the testing (I need explanation) and/or set up a linux machine with my controller connected + remote access.

[dripsnek]

Testing would be great when a proposed fix comes out, for now I think there's enough data between the tickets to figure out where the problem resides.

[dripsnek]

How are you running InputPlumber? A distro package, local compilation, or both?

[Switch123456789]

How are you running InputPlumber?

I used this package:
http://aur.archlinux.org/packages/inputplumber-bin
But also tried this package:
http://aur.archlinux.org/packages/inputplumber-git

I'm on CachyOS and also tried the version from their sources.

[dripsnek]

If you're running a distro package then it's unlikely you're seeing duplicate profiles, I've updated the other ticket with my current thinking.